MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (75):

aloril_, amessina, Anssi, Beirdo, brfranse_, caelor, Captain_Murdoch, CeilingKitten, Chutt, clever, coling, Cougar, danielk221, dblain, dekarl, dturner, eharris, ElmerFudd, fetzerch, foobum, ghoti, Gibby, gregL, GreyFoxx, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe____, johanbr, joki, jpharvey, jst_, jwhite, jya, kc, kurre2, kwmonroe, laga_, moparisthebest_, MythBuild, MythLogBot, nephyrin, neufeld, Nothing4You, nyloc, peper03, poptix, purserj, rhpot1991, robink, rsiebert, rsiebert___, seld, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang1, XDS2010, xris, _charly_
Monday, October 28th, 2013, 00:37 UTC
[00:37:07] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has joined #mythtv
[00:37:07] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[00:37:07] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Changing host)
[03:00:05] rsiebert_ (rsiebert_!~quassel@g225055232.adsl.alicedsl.de) has joined #mythtv
[03:02:17] rsiebert___ (rsiebert___!~quassel@g225055232.adsl.alicedsl.de) has joined #mythtv
[03:02:40] rsiebert (rsiebert!~quassel@g224248108.adsl.alicedsl.de) has quit (Ping timeout: 246 seconds)
[03:03:23] rsiebert__ (rsiebert__!~quassel@g224248108.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds)
[03:11:22] _nyloc_ (_nyloc_!~quassel@p3EE2C6C7.dip0.t-ipconnect.de) has joined #mythtv
[03:15:15] nyloc (nyloc!~quassel@p3EE2C9AE.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds)
[03:21:52] gigem: stuartm, paul-h: Ah, okay. I didn't even know we had scripting examples nor those limitations. I'll try to pay more attention next time I work on the services.
[03:45:32] DarkOne (DarkOne!~DarkOne@c-98-238-234-235.hsd1.ca.comcast.net) has joined #mythtv
[03:46:13] DarkOne (DarkOne!~DarkOne@c-98-238-234-235.hsd1.ca.comcast.net) has left #mythtv ()
[03:51:54] peper03_ (peper03_!~peper03@mythtv/developer/peper03) has joined #mythtv
[03:56:11] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[03:56:11] peper03_ is now known as peper03
[04:01:26] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has joined #mythtv
[04:27:31] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 245 seconds)
[04:28:50] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[05:03:07] bas-t (bas-t!~tycho@52484E89.cm-4-1b.dynamic.ziggo.nl) has quit (Quit: Ex-Chat)
[07:04:14] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has joined #mythtv
[07:13:43] dekarl: jya: understandable
[07:48:59] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[08:12:51] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[09:03:25] stuartm: gigem: I didn't know they existed either, in fact I wasn't even aware of the GetRecordedList() example until Paul mentioned that it was broken despite the fact that I'd been working in that area for a week
[09:03:54] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[09:05:52] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[09:09:56] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[09:24:02] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[09:39:19] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:cd86:4e9a:8870:3aee) has joined #mythtv
[09:46:37] Steve-Goodey (Steve-Goodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[11:14:32] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[11:21:14] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[11:28:34] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[11:45:01] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has joined #mythtv
[11:51:20] stuartm: skd5aner: so I was forgetting that we already had http auth support built-in, and that it's already used to protect access to the setup pages, we can very easily extend that to cover all pages
[11:51:57] stuartm: in which case, it's only https, to protect man in the middle on login credentials that's needed
[11:55:57] stuartm: we might even be able to construct it so that you're always prompted for your login if you're coming from an external IP (optionally not an internal IP*)
[11:57:19] stuartm: * Many NAT routers will detect/block clients spoofing an internal IP on the external interface, so it should be safe for most setups
[11:57:50] MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Quit: Leaving)
[12:08:34] Steve-Goodey (Steve-Goodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[12:20:12] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving)
[12:21:01] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[12:28:39] stichnot: stuartm: I sure wish MythUI operations could be done outside the UI thread. :( The GuideGrid class has lots of methods that create/update the guide entries based on blocking DB or backend queries. I'm trying to figure out the best way to deal with this
[12:30:15] stuartm: stichnot: the only thing that can't be done in the UI thread is populating widgets, actually looking up the data then posting back the result as an event to the UI thread is generally the way to do it
[12:30:42] stichnot: Even moving the cursor around without scrolling causes a DB query, it's a wonder there aren't more complaints about TV playback stuttering in the guide
[12:31:49] stuartm: stichnot: although my preferred fix for the guide issue was to query the tuner status etc just once when we load the guide, then have the scheduler/recorder send events notifying of changes in tuner status with which we could then update the UI
[12:32:47] stuartm: stichnot: that's age-old behaviour, when the mythui guide was created it wasn't a clean break from the past but a copy/paste of the old (broken) code, no-one has ever got around to doing it properly
[12:32:58] stichnot: ok
[12:34:45] stuartm: checking the db on every movement is of course unacceptable, as is constantly polling the tuner status on movement through the guide as though it's likely to have changes in the last few ms (it might, but that's not going to be the case 99.9% of the time)
[12:36:20] dblain: stuartm: re:ssl, it seems that it should be fairly straight forward to use QSslSocket where we use QTcpSocket. I'll add it to my list of things to do. (Focusing on Websockets first).
[12:36:37] stuartm: stichnot: I'm not exactly sure where the event needs to be sent, but a simple "TUNER_STATE_CHANGE {list of busy tuners}" would simplify things enormously
[12:36:47] stuartm: dblain: cool
[12:37:34] stichnot: One problem is, the scheduler functionality doesn't currently exist that could give the needed updates. E.g., RemoteRequestFreeRecorderList() and others take the excluded_cardids argument (which is populated by the current Live TV card for this frontend), and the result is customized for that.
[12:38:21] stichnot: stuartm: TUNER_STATE_CHANGE: that is essentially already there via the recording-started and recording-ended events
[12:39:53] stichnot: btw, there's already code that conservatively invalidates cached data once a minute
[12:53:42] stuartm: stichnot: unfortunately changing mythui to use lots and lots of locking just so that it can be thread safe would only make things much more complicated, slower and liable to months/years of edge/corner case deadlocks
[12:54:12] stuartm: and it won't fix the deeper issues in the recorder code
[12:54:20] stichnot: yeah, that's clear
[12:55:43] stuartm: I just traced through RemoteRequestFreeRecorderList() and it's gets worse with the deeper you descend, it's a tangled mess of code that I'm honestly surprised works as well as it does
[12:56:33] stichnot: unfortunately I'm responsible for the outer layer of that :(
[12:57:56] stichnot: the original code is in the #if 0 section, whereas the new code made use of excluded_cardids and allowed us to fix Live TV tuning bugs within the release and without protocol changes
[12:59:48] stichnot: anyway, I'm going to have a look at having a helper thread manage a cache of all the Program and tuner status data
[13:00:47] stuartm: I can't tell anyone how to fix it or that it should be fixed, but if I had the time and inclination I'd circumvent all the wrappers etc and have a single intermediary class (previously mentioned as backend context) the sole purpose of which is to track the status of free/available tuners, connected clients and that sort of thing – the low level recorder would actively update the state as required and high level code would then be able to query it
[13:02:57] stuartm: it would cut through all the years of accumulated clutter which could in time be eliminated, in theory at least, real world always has a way of trampling such plans underfoot
[13:06:31] stichnot: do you see this as caching just backend tuner state, or additionally caching the Program and Recorded data?
[13:07:28] stichnot: e.g., the big remaining delay in bring up the Watch Recordings page is loading the initial data
[13:10:35] stuartm: tuner state, hadn't considered Program/Recorded data, since we don't need to reload those constantly (they are cached in the frontend anyway) and besides they are straight loads from the database unlike tuner state, scheduler state, client state etc which are all kept in-memory anyway just not in one simple to access form
[13:13:21] stuartm: there was a programinfo caching and update mechanism created for Watch Recordings, might be possible to take that, build on it and cache all ProgramInfo in the frontend, for the life of the frontend
[13:13:54] stuartm: or at least for the duration of livetv, so you're not having to reload it each time the user enters the guide
[13:14:53] stuartm: lazy loading guide data more than a day in the past/future might also be a good way of speeding it up
[13:15:15] stuartm: and it would kept memory usage down vs caching everything
[13:21:28] stichnot: stuartm: just an aside, the Watch Recordings caching breaks if the frontend loses connectivity when an update happens
[13:23:14] stichnot: I think you need to have complete caching of guide timeslot data, perhaps title/subtitle as well, with lazy loading of the rest of the details
[13:23:46] stuartm: stichnot: we need a mechanism to force a reload after a reconnect
[13:24:53] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv
[13:26:44] stuartm: stichnot: there's not much advantage to caching partial program data, it wouldn't be any faster than loading everything – less initial network load perhaps, but same wall-time and then a lot of redundant queries on the DB to pull in the missing info
[13:31:17] stuartm: hmm, I take that back, there's a ~30% difference between SELECT * FROM program and SELECT title, subtitle FROM program
[13:32:47] stichnot: "select * from program;" for me returns 250K lines and 234M characters – "select title, subtitle from program;" 55M characters (mostly spaces)
[13:33:45] stuartm: although the initial load should have to include the rest of the data anyway, so you're better off just paging the data by time – SELECT * FROM program WHERE starttime > x AND starttime < y;
[13:34:26] Merlin83b: You'd need at least starttime and chanid too, I think?
[13:35:34] Merlin83b: Beat me to it :)
[13:37:46] stuartm: loading the data in batches would in theory happen so quickly that the user wouldn't even be aware of it – the initial load includes the first day, by the time they've been able to hit NEXTDAY at least two more days worth should already have loaded
[13:38:24] stuartm: but if the user is in livetv then most of the time they are browsing what's currently on or showing next, not what's on in a weeks time
[13:41:03] SteveGoodey (SteveGoodey!~steve@host109-158-208-19.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[13:42:10] stuartm: similarly, we can load future data first, before historical data
[13:43:31] stuartm: stichnot: how many lines if you add "WHERE starttime > NOW();" ?
[13:46:27] stichnot: stuartm: 127K, so ~50%
[13:47:13] stuartm: which makes sense, since we keep 14 days of old data, in addition to the 14 days you'll get from SD
[13:47:13] stichnot: seems strange, I thought we only kept 1 week of old data? I have 2 weeks into the future
[13:47:20] stichnot: oh, ok
[13:48:16] stuartm: that was changed by sphery, partly because I'd come back from a two week holiday at one point to find something hadn't recorded and I didn't have the guide data to tell what had gone wrong :)
[13:49:34] stichnot: :)
[14:16:16] tris (tris!tristan@2001:1868:a00a::4) has quit (Excess Flood)
[14:16:45] tris (tris!tristan@2001:1868:a00a::4) has joined #mythtv
[14:50:40] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Read error: Operation timed out)
[15:04:04] skd5aner: stuartm: very cool! gotta love when the framework is already built for you to use :) thanks for the update
[15:09:50] skd5aner: stuartm: I'm still getting daily crashes of mythbackend on my master backend :( The log files are ~800MB for a single day because it's -v socket,network --loglevel=debug. Any advice on how to get those to you guys for review? can I use a dropbox or somethng?
[15:10:08] skd5aner: stuartm: compressed, it's 25MB
[15:11:52] sphery: yeah, we now keep 10 days of old listings (because that matches up with the 10 days we keep matching (matched a rule), non-recorded entries from the oldrecorded table (recording history) to make it easier to figure out why things didn't record (rather than 7 days of listings and 10 days of history)
[15:14:48] sphery: though there's an old setting (that has no widget) that can be used to change it--so maybe you set yours to 14 days, or the 10 day window vs 14 days has about the same amount of listings (i.e. due to sparse data at the end of the 2 weeks)... but overall, probably going to be about half
[15:15:31] sphery: I'd be happy removing the old setting, but even when I made changes, there was no widget for that setting (it was put there only for development/testing)
[15:16:01] sphery: so I just left it rather than scare people or make them think I was taking away any functionality/flexibility
[15:16:59] skd5aner: sphery: you know something about trying to get a core file to dump with a segfault, correct?
[15:17:10] skd5aner: I remember seeing some commits from you related to that
[15:33:14] sphery: skd5aner: I think it was stichnot who did stuff related to the core files. About all I know is: http://www.mythtv.org/wiki/Debugging#Using_core_files
[15:33:32] skd5aner: sphery: thanks... yea, I can't get one to dump :/
[15:34:14] skd5aner: stuartm: #11927 – please let me know if you want to see the full logs somehow
[15:34:14] ** MythLogBot http://code.mythtv.org/trac/ticket/11927 **
[15:34:55] skd5aner: This segfault has happened every day for the last week :/
[15:37:01] danielk221 (danielk221!~danielk@exchange.wgen.net) has joined #mythtv
[15:55:02] stuarta: skd5aner: you need to modify your init script, so that you set `ulimit -c unlimited`
[15:55:10] stuarta: that way it'll drop core
[15:55:36] skd5aner: stuarta: right now, I'm not using an init script, but I did do that from the cli prior to launching mythbackend
[15:55:55] stuarta: so it should be dropping core. did you get one?
[15:56:02] skd5aner: nope :/
[15:56:16] skd5aner: ~/core right?
[15:56:43] stuarta: not necessarily. it'll drop in the CWD of the process at the time
[15:56:52] stuarta: so often /
[15:57:23] stuarta: do "lsof -p `pidof mythbackend` | grep CWD"
[15:58:51] skd5aner: no /core or /root/core either
[15:59:04] bill6502 (bill6502!~bill@205.178.26.43) has joined #mythtv
[15:59:53] stuarta: skd5aner: locate core
[16:00:11] stuarta: if you aren't using locate then maybe `find / -name core\* -print`
[16:00:14] skd5aner: stuarta: I did that, none anywhere
[16:00:22] skd5aner: didn't do a find
[16:00:27] skd5aner: did the locate
[16:00:44] bill6502: skd5aner: and if you're using Mythbuntu, apport will change the way core dumps are done. I turn it off: /etc/default/apport, enabled=0
[16:00:59] skd5aner: bill6502: don't use mythbuntu – I compile from source
[16:01:11] skd5aner: I do use ubuntu though
[16:01:42] stuarta: so if you don't mind the backend stopping as opposed to crashing, what you can do, is attach gdb to the process and then let is resume running, when it crashes gdb will catch it and stop the process in a state you can debug it (i suggest running gdb in a screen session)
[16:02:16] skd5aner: stuarta: true... I can try that...
[16:02:19] skd5aner: thanks
[16:02:21] dekarl1 (dekarl1!~dekarl@p4FE85ECF.dip0.t-ipconnect.de) has joined #mythtv
[16:02:35] bill6502: skd5aner: sysctl kernel.core_pattern
[16:03:13] stuarta: skd5aner: if you do build from source, then the occasional removal of the old install is good practice, we've had lots of random cores over the years from older libs being loaded into newer builds
[16:03:58] skd5aner: stuarta: I used to do that every time, now I only do it between version upgrades
[16:04:14] skd5aner: bill6502: just run that command?
[16:04:34] bill6502: yes, says where core file can be put
[16:04:39] skd5aner: kernel.core_pattern = core
[16:05:09] sphery: yeah, see the link I gave-- bill6502 wrote up how to use that to set the name/location of the file
[16:05:15] dekarl (dekarl!~dekarl@p4FE856A7.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds)
[16:05:28] sphery: http://www.mythtv.org/wiki/Debugging#Using_core_files
[16:05:56] skd5aner: sphery: the wiki page is a bit confusing around the part where it says "For mythbackend, this is no longer required after 0.25pre [4a515ba]."
[16:06:24] skd5aner: Not sure what the heck that is referring to – what is not required?
[16:06:47] bill6502: so isn't the ulimit that of mythtv, not $USER if you're starting with --user mythtv
[16:08:10] skd5aner: maybe this is it: sysctl kernel.core_pattern
[16:08:15] skd5aner: currently set to 0
[16:08:27] skd5aner: er, sorry
[16:08:34] skd5aner: wrong one... sysctl kernel.core_uses_pid
[16:08:34] skd5aner: kernel.core_uses_pid = 0
[16:09:06] bill6502: sphery: the line above: sudo sysctl -w fs.suid_dumpable=2 is no longer required. It's ancient, I'll remove it if you like
[16:09:39] sphery: bill6502: sounds good
[16:09:41] skd5aner: bill6502: that's what mine is set to, does that matter?
[16:09:54] sphery: skd5aner: and that's the only part that's not required (the rest is stuff you should do)
[16:11:10] sphery: and I'm guessing that's the stuff you remembered me doing (or, really, pushing for bill6502  :)
[16:13:00] sphery: skd5aner: though if you're seeing a warning, "Unable to re-enable core file creation. Run without the --user argument to use shell-specified limits." you'll want to just run mythbackend directly without the start script stuff and without --user argument (i.e. in a shell running as mythtv user)
[16:14:21] sphery: skd5aner: the fs.suid_dumpable=2 is fine--it's just more permissive than need be (means if you run other applications suid root, it will be able to create core files for them--which could result in writing privileged information to the file system where someone could find it)
[16:14:54] skd5aner: sphery: that's what I just did... I ran it as the user and removed the --user arguement
[16:14:57] skd5aner: let's see if that helps
[16:15:54] skd5aner: needless to say – wife is getting frustrated that when she turns on the TV every morning, she's created with a "mythbackend is offline" message :/
[16:16:13] skd5aner: s/created/greated
[16:16:19] skd5aner: created – greated – same thing
[16:16:23] skd5aner: :S
[16:17:04] bill6502: sphery: done (Wiki)
[16:41:27] SteveGoodey (SteveGoodey!~steve@109.158.208.19) has joined #mythtv
[16:57:17] FabriceMG (FabriceMG!~Thunderbi@217.112.59.207) has quit (Quit: FabriceMG)
[16:59:16] stuartm: skd5aner: only the last few lines are likely to be relevant
[17:01:25] stuartm: skd5aner: locate works from a database that is updated periodically (once a day it seems by my system), you need to 'updatedb' before it will find files created within the last few minutes/hours
[17:03:16] skd5aner: stuartm: I did do the updatedb first :)
[17:03:44] stuarta: that's why the find is the alternative :)
[17:03:51] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[17:03:58] stuartm: skd5aner: sorry, I had to say it because you'd be surprised how many people don't know that
[17:05:12] skd5aner: stuartm: no worries, I appreciate you mentioning it just in case – The number of things I don't know about various *nix-isms far outnumbers the things I do know :)
[17:06:38] stuartm: who, aside from Stallman, can really know it all?
[17:07:14] skd5aner: I know a few people who /think/ they do :-P
[17:08:20] stuartm: skd5aner: so the log confirms that it is a slave socket/disconnect issue, that may get us closer to the cause, I'll try to take a look at the code tonight or tomorrow
[17:08:59] skd5aner: stuartm: I greatly appreciate it. Is there anything else I can provide to assist?
[17:09:21] stuartm: seems slaves sockets are full of problems in 0.27, probably since the socket re-write :/
[17:09:57] stuartm: skd5aner: bt may be useful assuming it tells us more than it did for the other segfaults
[17:10:14] stuartm: but I'll know better when I actually look into it
[17:10:15] skd5aner: hopefully I'll get one overnight, if so I'll add it to the ticket
[17:10:27] skd5aner: thanks – just ping if you need anything
[17:11:08] stuartm: log seems to imply that it was recording at the time, was that the case?
[17:11:31] skd5aner: I'd have to go back and check – timestamps in the logs are in local time, correct?
[17:11:55] stuartm: err, yes ...?
[17:12:17] stuartm: I'd assume so, but I don't actually knpw
[17:12:20] stuartm: know
[17:12:28] skd5aner: I think the filename of the logs uses UTC, but the timestamps in the log are local
[17:12:31] stuartm: yes, local time
[17:13:32] stuartm: jya: when running without mythlogserver, would it be possible to strip out the redundant process name?
[17:13:49] stuartm: "Oct 26 12:20:56 scafell mythbackend: mythbackend[2601]:"
[17:15:00] skd5aner: stuartm: I think it was recording in the 10/26 example, but in the 10/27 example, I don't believe the slave was recording
[17:20:45] bill6502 (bill6502!~bill@205.178.26.43) has left #mythtv ()
[17:26:51] jheizer_ (jheizer_!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Read error: Connection reset by peer)
[17:28:54] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[17:33:38] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:cd86:4e9a:8870:3aee) has quit (Quit: Leaving)
[17:52:38] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Read error: Connection reset by peer)
[17:52:48] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:52:56] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[18:25:40] GreggN (GreggN!~gregg000@173.161.3.169) has joined #mythtv
[18:25:55] GreggN (GreggN!~gregg000@173.161.3.169) has left #mythtv ("Leaving")
[18:34:52] buu (buu!~buu@75.108.230.252) has joined #mythtv
[18:34:59] buu (buu!~buu@75.108.230.252) has left #mythtv ()
[18:59:31] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[19:05:20] jpabq: There is a memory leak in MythDownloadManager. I have been playing with the HLS stuff, and trying to track down a mem leak. I finally changed the HLS code to directly use QNetworkAccessManager instead of MythDownloadManager, and that fixed the leak while recording HLS.
[19:08:02] jpabq: I have looked over MythDownloadManager, but have not spotted the problem. I would appreciate it if someone else could take a look through the code, and maybe spot what I am missing. The HLS recorder uses the MythDownloadManager::download(const QString &url, QByteArray *data, const bool reload) entry point.
[19:09:20] jpabq: For the HLS recorder, using a more direct access to QNetworkAccessManager isn't bad, except that I would have to flush out usage of authentication and redirection.
[19:11:37] skd5aner: stuartm: I'm getting the other behavior we saw a week or 2 ago – "No Recordings available" in the frontend and VERY slow behavior – with mythcontext randomly telling me the backend is online
[19:11:57] skd5aner: stuartm: want me to try and get a backtrace right now or is the one I provided a few weeks ago good?
[19:29:05] brfranse_ (brfranse_!~brfransen@64.179.169.226) has joined #mythtv
[19:30:33] nyloc (nyloc!~quassel@p3EE2C6C7.dip0.t-ipconnect.de) has joined #mythtv
[19:30:38] brfransen (brfransen!~brfransen@64.179.169.226) has quit (Ping timeout: 272 seconds)
[19:31:16] aloril_ (aloril_!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has quit (Ping timeout: 272 seconds)
[19:31:48] moparisthebest_ (moparisthebest_!~quassel@cpe-184-57-178-66.cinci.res.rr.com) has joined #mythtv
[19:31:54] _nyloc_ (_nyloc_!~quassel@p3EE2C6C7.dip0.t-ipconnect.de) has quit (Ping timeout: 272 seconds)
[19:31:54] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has quit (Ping timeout: 272 seconds)
[19:32:28] skd5aner (skd5aner!~skd5aner@50-90-5-146.res.bhn.net) has joined #mythtv
[19:33:10] moparisthebest (moparisthebest!~quassel@cpe-184-57-178-66.cinci.res.rr.com) has quit (Ping timeout: 272 seconds)
[19:34:10] skd5aner: stuartm: #11929 captures the other event that I had been seeing previously – it may all be related, but I figured I'd submit the info just in case it's slightly/completely different than #11927
[19:34:10] ** MythLogBot http://code.mythtv.org/trac/ticket/11929 **
[19:34:10] ** MythLogBot http://code.mythtv.org/trac/ticket/11927 **
[19:35:04] danielk221 (danielk221!~danielk@exchange.wgen.net) has quit (Ping timeout: 272 seconds)
[19:35:19] skd5aner: stichnot: I didnt quite get what you were saying the other day? "1. Navigating between on-screen items without scrolling;" – how do I navigate without scrolling?
[19:35:36] skd5aner: stichnot: you mean, across pages?
[19:36:05] danielk221 (danielk221!~danielk@exchange.wgen.net) has joined #mythtv
[19:40:04] jpabq: skd5aner: Can you try http://code.mythtv.org/trac/attachment/ticket . . . change.patch with your HD-PVR recordings/playback sometime ?
[19:43:06] aloril_ (aloril_!~aloril@dsl-tkubrasgw3-54f97e-153.dhcp.inet.fi) has joined #mythtv
[19:50:56] skd5aner: stichnot: #11020 – I updated the ticket with the requested info, even though you said you might not need it anymore – just wanted to give you what I see – thanks for asking and hope it helps. Let me know if there's any more details you'd find helpful
[19:50:56] ** MythLogBot http://code.mythtv.org/trac/ticket/11020 **
[19:51:53] skd5aner: jpabq: yes, I'll recompile when I get home this evening... I need to remember which recordings I have the exhibit the behavior. I know I deleted at least a couple and I haven't had many new issues in the last 2 weeks with new recordings
[19:53:39] skd5aner: jpabq: although I did find some recordings made with 0.26 that exhibit the same behvior when played back in 0.27 – so it's a playback issue, not a recorder one
[19:53:47] skd5aner: and, I think they played back fine in 0.26
[19:54:16] skd5aner: I wasn't aware of any pre-0.27 recordings until recently, just watned to make you aware
[19:54:19] jpabq: That change could affect either/both recording and playback.
[19:54:45] skd5aner: *aware of any impacted pre-0.27 recordings – that is
[19:55:08] skd5aner: alright, got to run
[20:09:18] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Remote host closed the connection)
[20:14:31] stichnot: skd5aner: Thanks for the notes in the ticket. By "navigating without scrolling", I mean moving between items such that the set of channels stays the same and the displayed time window stays the same.
[20:14:49] joki (joki!~joki@p54860E1E.dip0.t-ipconnect.de) has quit (Ping timeout: 246 seconds)
[20:14:51] Gibby (Gibby!~Gibby@mylanupdates.eclipse.25u.com) has quit (Ping timeout: 248 seconds)
[20:20:11] joki (joki!~joki@p54860518.dip0.t-ipconnect.de) has joined #mythtv
[20:28:23] Gibby (Gibby!~Gibby@mylanupdates.eclipse.25u.com) has joined #mythtv
[20:36:44] SteveGoodey (SteveGoodey!~steve@109.158.208.19) has quit (Quit: Konversation terminated!)
[21:01:44] Chutt (Chutt!~ijr@2605:a000:1208:c084:28c4:8b4b:16ed:eea8) has quit (Read error: Connection reset by peer)
[21:02:20] Chutt (Chutt!~ijr@2605:a000:1208:c084:c457:ef1d:60fd:2177) has joined #mythtv
[21:06:46] Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit ()
[21:10:27] Gibby (Gibby!~Gibby@mylanupdates.eclipse.25u.com) has quit (Ping timeout: 260 seconds)
[21:20:18] Gibby (Gibby!~Gibby@mylanupdates.eclipse.25u.com) has joined #mythtv
[21:35:17] dekarl1 is now known as dekarl
[21:41:48] stuartm: I think the GetPreviewImage() logic for height/width is flawed, the docs state that you should only supply either height or width (not both) if you want to preserve aspect ratio, but you can't know in advance which of those is going to give you the best image to fill the available space
[21:43:03] stuartm: imagine a space 160x90, if you request by height it will work OK for 16:9 or 4:3, but for letterboxed material the resulting image will be too wide
[21:43:28] jheizer: I kind of hit that with mobilemyth
[21:43:45] jheizer: I ended up always specifying height and leaving room for width
[21:44:28] stuartm: I can't imagine a scenario where you'd want to ignore the aspect ratio of the image and even if you did, you can just stretch it client side instead (can't restore the correct aspect client side)
[21:44:59] stuartm: jheizer: so no objections if I change the behaviour?
[21:45:35] jheizer: In turn going to require both? or if both it will be smart enough to not go out of those bounds?
[21:45:43] stuartm: the behaviour is inconsistent with other image methods in the API anyway, they preserve aspect
[21:45:55] stuartm: jheizer: the latter
[21:46:00] jheizer: Really, doesn't matter to me either way. I'd be fine.
[21:46:16] stuartm: if you specify 160x90, it will return an image that is not larger in either direction
[21:46:31] stuartm: s/direction/dimension/
[21:46:52] jheizer: If both are required will add to the work I have to do to support old versions, but not the end of the world.
[21:47:06] stuartm: but it won't stretch it to fit, so it may return 140x90 or 160x80
[21:47:17] jheizer: Yeah, understood.
[21:47:34] stuartm: jheizer: won't require both, just behave differently if both are defined
[21:47:40] stuartm: given
[21:47:46] jheizer: Ok, cool.
[21:48:01] jheizer: Along those lines... in implementing the new gallery I hit this alot
[21:48:02] jheizer: actually
[21:48:09] jheizer: So will be a big help.
[21:48:14] jheizer: but... rotation.
[21:48:25] stuartm: jheizer: I'll fix it where-ever it's an issue
[21:48:52] jheizer: Any thoughts on exif support being added to the GetImage (or what ever it was called) request?
[21:49:06] stuartm: jheizer: it would be nice to have
[21:49:46] jheizer: I got a basic table/gallery view but the unrotated images makes it a bit messy.
[21:56:50] jheizer: I really need to dig into the myth code on of these years... Off to make dinner.
[21:59:23] rsiebert_ (rsiebert_!~quassel@g225055232.adsl.alicedsl.de) has quit (Ping timeout: 248 seconds)
[22:12:48] rsiebert (rsiebert!~quassel@g225055232.adsl.alicedsl.de) has joined #mythtv
[22:23:11] natanojl: skd5aner: #11306 might be related to your crashes and has a patch. I've tried it but it seems to introduce a deadlock instead :( I haven't looked into it in detail since my backends usually aren't powered on long enough for it to happen. And now it's time for some sleep...
[22:23:11] ** MythLogBot http://code.mythtv.org/trac/ticket/11306 **
[22:29:40] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 256 seconds)
[22:37:05] rsiebert (rsiebert!~quassel@g225055232.adsl.alicedsl.de) has quit (Read error: Operation timed out)
[22:38:34] rsiebert (rsiebert!~quassel@g225055232.adsl.alicedsl.de) has joined #mythtv
[23:05:25] stuartm: started working on the recordings page tonight, it has a long way to go yet, plenty of information still not displayed, but I thought I'd share it anyway – http://www.mythtv.co.uk/imagebin/internal_recordings.jpg
[23:07:36] stuartm: thinking about having that menu slide away to the left when it's not being used to free up precious screen real-estate
[23:38:02] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has quit (Quit: Oh No!!!! ;-))
[23:43:01] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[23:43:42] J-e-f-f-A (J-e-f-f-A!~J-e-f-f-A@unaffiliated/j-e-f-f-a) has joined #mythtv

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