| Thursday, August 15th, 2013, 00:08 UTC | ||
| [00:08:12] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [00:11:37] | Chutt_ (Chutt_!~ijr@76.190.199.73) has joined #mythtv | |
| [00:45:22] | dmfrey (dmfrey!~dmfrey@65-78-98-83.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has joined #mythtv | |
| [00:46:31] | dblain: | playing around with website designs for mythbackend... can we assume html 5 or should it still be compatible with old browsers? |
| [01:37:45] | stichnot (stichnot!~stichnot@adsl-68-127-208-81.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [01:37:45] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [01:37:45] | stichnot (stichnot!~stichnot@adsl-68-127-208-81.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [01:43:22] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [01:43:38] | jpabq: | dblain: what justification would someone have for using an old browser? Even MS has been trying to get people to upgrade their IE version. |
| [01:58:21] | joki (joki!~joki@p54862304.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [02:03:36] | joki (joki!~joki@p54863A52.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:13:36] | xris (xris!~xris@xris.forevermore.net) has quit (Excess Flood) | |
| [02:13:58] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [02:13:59] | xris (xris!~xris@xris.forevermore.net) has quit (Changing host) | |
| [02:13:59] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [02:15:50] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 245 seconds) | |
| [02:16:51] | dmfrey (dmfrey!~dmfrey@65-78-98-83.c3-0.smt-ubr1.atw-smt.pa.cable.rcn.com) has quit (Quit: Ex-Chat) | |
| [02:16:51] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [02:17:29] | wagnerrp_ (wagnerrp_!6b124e2f@gateway/web/freenode/ip.107.18.78.47) has joined #mythtv | |
| [02:22:45] | skd5aner: | dblain: you should most definitly be targetting HTML5. I really think mythtv needs to quit worrying about supporting anything conisdered "legacy" or "old" today, and really only focus on where things are headed... not where they're been |
| [02:24:08] | skd5aner: | People want innovation, not backwards compatibility. And who cares if you lose a dozen random users who want to use a 5 year old browser? I bet you wouldn't even lose that many... |
| [02:25:48] | nyloc (nyloc!~quassel@p3EE2D4FB.dip0.t-ipconnect.de) has joined #mythtv | |
| [02:27:57] | skd5aner: | look how long people have been "talking" about replacing mythtv-setup. 3+ years? It might be another 3 before it's done since progress has been basically halted for a long while, and no one actively taking the lead currently |
| [02:29:38] | skd5aner: | so, do it "right" – do some cool stuff, and think about how people are going to be using it 3 years from now, not if people are trying to use it on 10 year old hardware, OS's, and Browsers |
| [02:29:49] | ** skd5aner steps off soap box ** | |
| [02:30:09] | _nyloc_ (_nyloc_!~quassel@p3EE2D4A8.dip0.t-ipconnect.de) has quit (Ping timeout: 264 seconds) | |
| [02:32:35] | wagnerrp_: | skd5aner: i have to agree with you there |
| [02:32:46] | wagnerrp_: | we really need to make that a primary goal for 0.28 |
| [02:33:42] | skd5aner: | wagnerrp_: thanks, I know my opinion doesn't carry as much weight as others in this room, but I appreciate hearing your thoughts too |
| [02:34:09] | skd5aner: | wagnerrp_: do you simply mean "mythtv-setup" or "innovative features" as a goal (or both?) |
| [02:34:48] | wagnerrp_: | mythtv-setup in particular |
| [02:35:38] | skd5aner: | because, the last couple of releases (including the upcoming one) have had a lot of "under the covers" type of changes to them... I doubt the average user could tell you much of a difference in feature-sets between 0.25 and 0.27 (once released) |
| [02:36:12] | wagnerrp_: | i was actually thinking specifically of mythtv-setup earlier today with #11748 |
| [02:36:12] | ** MythLogBot http://code.mythtv.org/trac/ticket/11748 ** | |
| [02:36:29] | wagnerrp_: | but i admit, i have plenty of my own planned features that have been delayed at least a release |
| [02:37:12] | skd5aner: | yea, the real world has a way of making your priorities for you |
| [02:39:34] | skd5aner: | back to my comment on worrying about keeping a very, very small subset of users who may want to support legacy hardware or software to run mythtv... I would be willing to wager that for every 1 user you'd lose for something like that, you'd be like to gain 50–100 new ones |
| [02:40:21] | wagnerrp_: | it's an issue that comes up almost every release |
| [02:40:31] | wagnerrp_: | dropping things like xvmc, pvr350 output, etc... |
| [02:40:39] | skd5aner: | it's such a SMALL minority |
| [02:40:43] | skd5aner: | very small |
| [02:41:05] | skd5aner: | and, it's one thing to rip it out with no alternative – but there's plenty of alternatives |
| [02:41:11] | skd5aner: | and who cares? |
| [02:41:53] | skd5aner: | XvMC isn't maintained... PVR-350's havent been sold in almost 8+ years |
| [02:42:06] | skd5aner: | and you can still use them to record |
| [02:42:38] | wagnerrp_: | going to opengl only (like xbmc) versus continuing to support xv was a big one |
| [02:42:39] | skd5aner: | I never understand the debate... and honestly, even the vocal minority aren't /that/ vocal |
| [02:43:05] | skd5aner: | yea... I know that's been a hot button issue before |
| [02:43:36] | skd5aner: | there's also a reason why 1000x more people have heard of XBMC versus MythTV |
| [02:43:54] | skd5aner: | It didn't really seem to impact their user base |
| [02:44:17] | skd5aner: | so why should MythTV think it would hurt theres? |
| [02:44:23] | skd5aner: | *theirs |
| [02:47:01] | wagnerrp_: | honestly, i'm not very pleased with the existing work on the web setup |
| [02:47:15] | wagnerrp_: | it still seems like it's designed for a 640x480 monitor |
| [02:47:15] | skd5aner: | I think my biggest dissapointment as a user in the last couple releases is that I deploy the new release when it comes out, and within 20 seconds, I can show my wife all the "new" features... it'd be nice if there was more on the surface to brag about |
| [02:48:17] | skd5aner: | that should be simple to adapt though... the foundation's there |
| [02:49:28] | wagnerrp_: | true, most of the work is in writing the services interfaces |
| [02:49:53] | skd5aner: | well – thanks for your thoughts :) time to head to bed |
| [02:54:07] | knightr_ (knightr_!~knight@69-165-170-178.dsl.teksavvy.com) has joined #mythtv | |
| [02:54:25] | knightr_ (knightr_!~knight@69-165-170-178.dsl.teksavvy.com) has quit (Remote host closed the connection) | |
| [03:10:21] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds) | |
| [03:11:27] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [03:18:17] | wagnerrp_ (wagnerrp_!6b124e2f@gateway/web/freenode/ip.107.18.78.47) has quit (Quit: Page closed) | |
| [03:45:09] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has joined #mythtv | |
| [04:29:59] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Read error: Operation timed out) | |
| [04:33:25] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [04:45:36] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [04:46:58] | dekarl: | we could even do something crazy and patch mythweb to use the nice JW Player and HLS streaming so it works on all the nice handheld devices OOTB ;) |
| [04:46:59] | dekarl: | The talk on http://www.mythtv.org/wiki/Talk:Volume_normalization made me wonder if that would be a nice feature for our night mode. Normalize to a final low volume so the baby doesn't wake up. |
| [04:50:42] | dekarl: | ^- and advertise more... Hands up, who knows night mode only because they ended up there accidently and had to debug the broken display? ;) |
| [04:54:10] | robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 245 seconds) | |
| [04:59:04] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [05:31:40] | robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 245 seconds) | |
| [05:37:07] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [05:44:04] | OldEnK (OldEnK!~OldEnK@63-152-103-245.cdrr.qwest.net) has joined #mythtv | |
| [05:45:20] | OldEnK (OldEnK!~OldEnK@63-152-103-245.cdrr.qwest.net) has left #mythtv () | |
| [05:46:15] | robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 245 seconds) | |
| [05:50:21] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [05:57:55] | robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 245 seconds) | |
| [06:02:08] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [06:02:52] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has quit (Ping timeout: 264 seconds) | |
| [06:07:46] | SteveGoodey (SteveGoodey!~steve@host86-164-55-78.range86-164.btcentralplus.com) has joined #mythtv | |
| [06:13:00] | OldEnK (OldEnK!~OldEnK@63-152-103-245.cdrr.qwest.net) has joined #mythtv | |
| [06:13:13] | OldEnK (OldEnK!~OldEnK@63-152-103-245.cdrr.qwest.net) has left #mythtv () | |
| [06:19:38] | SteveGoodey (SteveGoodey!~steve@host86-164-55-78.range86-164.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [06:22:50] | taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv | |
| [06:39:04] | Chutt_ (Chutt_!~ijr@76.190.199.73) has quit (Read error: Connection reset by peer) | |
| [06:39:28] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [06:45:50] | robink (robink!~quassel@unaffilated/robink) has quit (Ping timeout: 245 seconds) | |
| [06:47:15] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has quit (Remote host closed the connection) | |
| [06:48:02] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [06:48:28] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [06:50:20] | robink (robink!~quassel@unaffilated/robink) has joined #mythtv | |
| [07:08:57] | Chutt__ (Chutt__!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [07:11:50] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Ping timeout: 240 seconds) | |
| [07:32:22] | Chutt_ (Chutt_!~ijr@cpe-76-190-199-73.neo.res.rr.com) has joined #mythtv | |
| [07:35:34] | Chutt__ (Chutt__!~ijr@cpe-76-190-199-73.neo.res.rr.com) has quit (Ping timeout: 240 seconds) | |
| [08:04:30] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:50b3:8df8:dabe:ac59) has joined #mythtv | |
| [08:15:39] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has joined #mythtv | |
| [08:39:51] | Merlin83b: | Probably one for stuarta. I'm running a fairly old version (0.25 fixes) so this may be out of date, but a bunch of channels in the UK DVB EIT (I'm on DVB-S) have started putting new showings with the title of "New: <title>" (BBC3) or a title of "New:" and the show as the subtitle (Channel 5). Sounds like a fixup candidate if it's not already in there. |
| [08:42:37] | Merlin83b: | I'd be happy to file a trac ticket if it's worthwhile, but thought a check here would save the trouble if it's been done already. |
| [08:48:27] | Merlin83b: | Then I searched and found it in #11715. I did choose stuarta correctly, though ;) |
| [08:48:27] | ** MythLogBot http://code.mythtv.org/trac/ticket/11715 ** | |
| [08:50:11] | Merlin83b: | Guess I need to set aside some upgrading time :) |
| [09:19:33] | foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has quit (Ping timeout: 268 seconds) | |
| [09:24:12] | foxbuntu (foxbuntu!~foxbuntu@97-125-137-182.desm.qwest.net) has joined #mythtv | |
| [09:24:17] | foxbuntu (foxbuntu!~foxbuntu@97-125-137-182.desm.qwest.net) has quit (Changing host) | |
| [09:24:18] | foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has joined #mythtv | |
| [09:28:44] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [10:24:24] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [10:25:18] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Client Quit) | |
| [11:12:08] | Merlin83b2 (Merlin83b2!~Daniel@2a00:1ee0:3:1337:50b3:8df8:dabe:ac59) has joined #mythtv | |
| [11:15:14] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:50b3:8df8:dabe:ac59) has quit (Ping timeout: 264 seconds) | |
| [11:46:06] | rambo3 (rambo3!c2daef82@gateway/web/freenode/ip.194.218.239.130) has joined #mythtv | |
| [12:04:03] | rambo3 (rambo3!c2daef82@gateway/web/freenode/ip.194.218.239.130) has quit (Quit: Page closed) | |
| [12:10:28] | jya_: | that whole libmythmetadata leaks everywhere.. no objects is ever deleted, parents never delete the metadata objects, threads aren't set to quit... quite worrying... |
| [12:18:22] | stuartm: | I fixed a number of leaks in there, but I never went through it systematically |
| [12:18:48] | stuartm: | it is very worrying :/ |
| [12:20:40] | ** Seeker` imagines a hushed, david attenborough voice, "And here we see the squalid conditions of memory in libmythmetadata. Objects abandonded by parents, theads left running forever..." ** | |
| [12:22:31] | clever: | lol |
| [12:23:05] | jya_: | stuartm: i was investigating #11751.. as no object is ever deleted when the video dialog is dismissed, it gets called by all the objects/thread it has created in the mean time. |
| [12:23:05] | ** MythLogBot http://code.mythtv.org/trac/ticket/11751 ** | |
| [12:24:49] | jya_: | i thought it was going to be an easy fix... but once I opened the box, started to look on how it was used elsewhere... the delete statement is a rare entity. funnily, all those objects derive from QObject and take a parent in their constructor, but as the QObject constructor is never called, can't even enjoy the Qt auto-delete |
| [12:25:52] | stuartm: | my understanding was, and this was a long time ago, before it was re-written more than once, was that the video list was intentionally cached globally (for X minutes) so that the screen would be displayed faster when re-entering or when switching between the different views |
| [12:27:03] | stuartm: | but it sounds like it was implemented badly and/or broken by subsequent additions/rewrites |
| [12:27:25] | jya_: | oh here I've only looked at the metadata stuff. the things call when you scan videos (and it's marked to search for metadata) or when you do info -> retrieve data on a video |
| [12:28:23] | jya_: | it can start several threads at once that call the tmdb python scripts |
| [12:31:25] | jya_: | so don't know if there's anything cache on top of that ... certainly doesn't seem so... each time you quite the video screen that one is deleted automatically by mythui, and all the various metadata objects and children are fully recreated. |
| [12:34:02] | stuartm: | :/ |
| [12:42:21] | jya_: | for the time being, when you quite the video dialog, i'm just going to kill anything ongoing... problem is that all those classes are using pointers to metadataobject shared across all instances. so it's unsafe to kill them without killing everything. a pity, it could have been easily made to continue its work in the background and get deleted automatically once completed, even if you have exited mythvideo |
| [12:45:14] | stuartm: | there's a flag of some sort that gets set on videos when we've looked up (or started to lookup) their metadata, I know in the past when I've killed the frontend during a lookup that it then never resumes scanning for the missing metadata and you have to specifically request a lookup for each (and every) video :( |
| [12:45:21] | stuartm: | could use some TLC |
| [12:46:49] | stichnot (stichnot!~stichnot@216.239.45.130) has joined #mythtv | |
| [12:46:49] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [12:46:49] | stichnot (stichnot!~stichnot@216.239.45.130) has quit (Changing host) | |
| [12:52:30] | jya_: | stuartm: yes, each metadataobject can write into the database... I do see the cached video screen content you're referring to... it gets kills after 3s.. this is used when changing video display type... |
| [12:52:50] | jya_: | killed (damn autocorrection) |
| [13:17:58] | jya_: | jeez... it's even worse than I thought it was... the objects retrieved from the data lookup, get added to the list, processed.... and just remove from the list .. never deleted either... |
| [13:18:09] | jya_: | oh well.. too much for tonight.. will go to bed |
| [13:18:16] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [14:22:09] | bobweaver: | Hello there I have noticed that there is a bug in the services api with frontend actions. The "keys" MOUSE[UP,DOWN,LEFT,RIGHT] do not work. I have tested this on 4 machines and made a touchpad and it will not work. Where do I file bug ? |
| [14:22:12] | bobweaver: | !bug |
| [14:24:21] | stuartm: | sphery: one argument, albeit a weak one, for allowing livetv storage groups is to put livetv on a faster drive to give a very slight boost in the channel change times |
| [14:24:50] | stuartm: | but otherwise I agree, it doesn't make much sense |
| [14:25:58] | stuartm: | you might choose to allow recording drives to spin down when idle, which would be undesirable for livetv drives ... |
| [14:27:02] | sphery: | stuartm: Yeah, though I'll bet the difference is very small when comparing HDD to HDD. I think some have it so that they have all-remote storage on their backend(s) and just have a single local file system for Live TV, and that would likely give you a bigger difference in performance, but I'd guess that configuration isn't too common. |
| [14:27:29] | sphery: | and I would be interested in just /how much/ a difference it makes |
| [14:28:16] | sphery: | but I would guess that the vast majority of users have configured Live TV SGs--many identical to Default SG (in which case it's actually /bad/ to have it since you have to update both SG dir lists to add new storage, and likely people don't update the Live TV one) |
| [14:28:31] | stuartm: | I was thinking SSD to HDD – SSD might not be the most suitable medium for recordings but I suppose some people have got money to burn |
| [14:28:59] | sphery: | I'd actually like to take out all the "you don't need it, but can use it if you really want to control everything" create SG buttons--so, at least, Live TV and DB Backups |
| [14:29:01] | stuartm: | have money to burn |
| [14:30:01] | sphery: | yeah, still don't think there'd be that much difference in Live TV startup with SSD vs HDD for recording file storage (though SSD for MySQL data storage might make a pretty noticeable difference--especially depending on the MySQL/file system configuration) |
| [14:30:28] | stuartm: | aye, no need to make advanced settings like those so prominent, the first run through setup should be a wizard experience with just the basics needing to be configured |
| [14:30:57] | sphery: | agreed... and having a specific button for it makes users think they need to do that |
| [14:34:13] | sphery: | I'll put that on my TODO list for after 0.27 release... Update the UI for the SG creation and try to give more/better instruction to users. |
| [14:35:53] | sphery: | yay, more "don't upgrade to 0.26, it's horrible" posts :( |
| [14:39:12] | stuartm: | what's wrong this time? |
| [14:40:19] | sphery: | takes more memory/CPU, can't run on a Core 2 Duo 2GHz with 2GB ram |
| [14:40:39] | sphery: | (likely because of something unrelated to MythTV, like running with barriers on the file system or ...) |
| [14:42:15] | sphery: | It's frustrating because every time we recommend that users run the currently-supported stable version, a bunch of people pop up with "horror" stories about how terrible "MythTV" is, and I would bet that their problems are not caused by MythTV but by other changes to their configuration they got when they upgraded things along with MythTV |
| [14:42:29] | sphery: | so more people back away from current, stable MythTV in fear |
| [14:43:23] | sphery: | I really want to scream out, "Your failure to configure your system properly for MythTV is not an indicator of whether or not others should run the current, stable version of MythTV." |
| [14:43:34] | bobweaver: | lol |
| [14:45:06] | sphery: | sorry, just one of those days, so I'm in a mood where I should probably stay away from the lists/irc :) |
| [14:45:52] | stuartm: | sphery: they are probably also trying to run themes like MythAeon which are intensive instead of the themes they used with 0.25 |
| [14:47:09] | stuartm: | 0.26.1 has been tagged |
| [14:59:30] | wilmoore-misc (wilmoore-misc!~wilmoore@c-67-190-17-108.hsd1.co.comcast.net) has quit (Remote host closed the connection) | |
| [15:00:54] | sailerboy (sailerboy!~sailerboy@sailerboy.net) has joined #mythtv | |
| [15:01:14] | sailerboy (sailerboy!~sailerboy@sailerboy.net) has left #mythtv ("Leaving") | |
| [15:19:51] | danielk22 (danielk22!~danielk@exchange.wgen.net) has joined #mythtv | |
| [15:34:27] | gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.1) | |
| [15:35:28] | gigem (gigem!~david@pool-96-226-13-10.dllstx.fios.verizon.net) has joined #mythtv | |
| [15:35:28] | gigem (gigem!~david@pool-96-226-13-10.dllstx.fios.verizon.net) has quit (Changing host) | |
| [15:35:28] | gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv | |
| [15:40:26] | wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv | |
| [16:06:39] | dekarl1 (dekarl1!~dekarl@p4FE844D7.dip0.t-ipconnect.de) has joined #mythtv | |
| [16:08:23] | dekarl (dekarl!~dekarl@p4FCEFC36.dip0.t-ipconnect.de) has quit (Ping timeout: 240 seconds) | |
| [16:26:23] | rsiebert (rsiebert!~quassel@e179135165.adsl.alicedsl.de) has joined #mythtv | |
| [16:29:59] | rsiebert_ (rsiebert_!~quassel@e179168125.adsl.alicedsl.de) has quit (Ping timeout: 268 seconds) | |
| [16:36:20] | Steve-Goodey (Steve-Goodey!~steve@host86-164-55-78.range86-164.btcentralplus.com) has joined #mythtv | |
| [16:44:24] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [16:54:17] | Merlin83b2 (Merlin83b2!~Daniel@2a00:1ee0:3:1337:50b3:8df8:dabe:ac59) has quit (Quit: Leaving) | |
| [17:07:39] | stichnot: | sphery: I vaguely recall an issue regarding LiveTV storage groups, having to do with the need for certain NFS parameters. I had to follow that advice when I had a diskless slave backend that recorded into an NFS-mounted directory. Without that advice, Live TV would fail with that recorder. |
| [17:07:44] | stichnot: | Does that ring a bell? |
| [17:09:26] | stichnot: | sphery: don't forget people who upgrade to 0.xx instead of 0.xx-fixes |
| [17:16:38] | danielk22: | stichnot: You need to disable or lower the attribute caching threshold with NFS volumes for LiveTV to work properly. Otherwise the file size will of the recording will remain 0 bytes and playback won't strart until the attribute cache expires (about a minute by default). |
| [17:22:39] | sphery: | stichnot: Right, as danielk22 said, you just have to set NFS to have either a very low TTL for file attribute caching or completely disable it (with -noac), but it's unrelated to the Live TV storage group (as you'd want the same for recording file systems, anyway, or else you'll have "nonexistent" file and "0-byte" file errors for everything from preview creation to commercial detection, etc. |
| [17:23:08] | stichnot: | sphery: good point. |
| [17:23:47] | danielk22: | A bit off topic, but are there any good network file systems to replace NFS with these days? |
| [17:24:23] | sphery: | really, I think the only time it makes some sense is when you have only a small local partition and everything else is remote, but even then, if your system can record normal shows to the remote file system, it should be able to record Live TV remotely, too |
| [17:24:32] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [17:26:18] | sphery: | and it will make even less sense to have a separate Live TV storage group once I make some time to work on MythTV and get the schema changes in that let us track the last-seen location of recording files so that we could make SG disk schedulers take into account what specific recordings would be expired from a given file system choice so it could preferentially write where Deleted recordings, then Live TV are expired |
| [17:27:13] | dekarl-work: | stuartm sphery: wrt LiveTV SG. IMHO it makes more sense to have channel surfing not spin up each and every disk for a 30 second LiveTV file. |
| [17:27:22] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [17:27:58] | dekarl-work: | sphery, I couldn't find (your?) hint on how to setup auto-expiry with the disk scheduler to avoid killing the newest recordings first :/ |
| [17:31:01] | sphery: | dekarl-work: basically, don't use Balanced Free Space or Balanced Percent Free Space when your file systems are nearly full and you're relying on autoexpire to delete things because it will probably write everything to the same |
| [17:32:12] | dekarl-work: | ahh, exactly what I'm doing... But now I know how to fix it :) ty |
| [17:33:06] | sphery: | dekarl-work: I don't know that it would spin up all the disks or if it only spins up the one(s) it's writing to (no idea whether checking file system stats spins up the disk). Regardless, my suggestion is to take out the button to create the Live TV SG, not to remove support for it. So those who want to use a specific disk/file system for Live TV could just create it themselves |
| [17:37:38] | sphery: | I'm actually thinking about removing all the "create special SG" buttons from the list of SG's and just having a button to create an SG, then allowing the user to select a "built-in" SG name or type one in themselves. And, if they select a built-in name, it will provide more information, such as, "All Live TV recordings will be stored to the Live TV Storage Group directories if this group is defined. Otherwise, Live TV will be stored in the ... |
| [17:37:44] | sphery: | ... Default Storage Group directories. Defining this group is unnecessary." |
| [17:38:18] | sphery: | but even just removing DB Backups and Live TV and making the user type the right name to define them (making it a "hidden" advanced setting) would be better than current. |
| [17:46:53] | dekarl-work (dekarl-work!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit () | |
| [17:52:04] | stuartm: | dekarl1: right, I didn't know we were doing that – we should be keeping track of how much space is available on each, we only need to spin up the one we are going to use |
| [17:53:28] | stuartm: | but that goes generally hand in hand with my pet hate, spinning up all drives to find a file when we should know exactly which drive it's on (that and searching all storage groups for a file) |
| [18:03:47] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [18:29:13] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has quit (Remote host closed the connection) | |
| [18:31:05] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has joined #mythtv | |
| [18:34:48] | ElmerFudd (ElmerFudd!~le@87-55-166-130-static.dk.customer.tdc.net) has joined #mythtv | |
| [18:40:42] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [18:43:51] | SteveGoodey (SteveGoodey!~steve@host86-164-55-78.range86-164.btcentralplus.com) has joined #mythtv | |
| [19:13:37] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 246 seconds) | |
| [19:25:49] | gigem: | dekarl1: You marked #11282 for fixing in 0.27.1. Since it requires a schema change, it needs to go in before any 0.27 branch is made or will have to wait until 0.28. FWIW, I don't see a problem with putting it in now. Also, rather than add an entirely new index, I'd probably add subtitle and starttime to the existing title index and tweak the SQL ordering to use it. |
| [19:25:49] | ** MythLogBot http://code.mythtv.org/trac/ticket/11282 ** | |
| [19:27:52] | bobweaver (bobweaver!~bobweaver@ubuntu/member/bobweaver) has quit (Changing host) | |
| [19:27:53] | bobweaver (bobweaver!~bobweaver@unaffiliated/bobweaver) has joined #mythtv | |
| [19:28:28] | tonsofpcs: | dekarl1: I'm not sure how #7205 relates to allowing recording ignoring PSIP or using last known PSIP on a lack of PSIP. |
| [19:28:28] | ** MythLogBot http://code.mythtv.org/trac/ticket/7205 ** | |
| [19:30:47] | tonsofpcs: | the issue here is that a broadcaster may have a device failure and be no longer populating MGT, EIT, ETT, ... but the pids are all still there. So a scheduled recording from 34.2 which is RF 34 Program 4 won't work when PSIP is missing currently but if PSIP were cached we would know that 34.2 was at 34–4 (and PIDs 0x40, 0x41, 0x44) |
| [20:03:30] | dekarl1 is now known as dekarl | |
| [20:28:33] | dekarl: | gigem: I have more schema changes in mind, so pushing them to 0.28 is fine for me. |
| [20:32:57] | dekarl: | tonsofpcs: for me the connection was that we have various areas where we can/should be more lax wrt the mandatory tables. Be it by making up missing tables in a "turn everything that comes down this pipe into one service" way |
| [20:32:59] | dekarl: | or caching results from the channel scan and only update it if we see a good table or even letting people manually enter the component PIDs that make up a service (IIUIC thats good to watch the various news uplinks on satelite) |
| [20:37:20] | dekarl: | we also have to make up tables for some HLS streams if we want to record everything that matches the spec (PAT/PMT *should* be present) |
| [20:38:52] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [20:43:49] | gigem: | dekarl: Okay. I was just going through some tickets I had noted and that one seemed like a very easy one to fix. |
| [20:47:45] | stuartm: | dekarl: since there's a considerable difference between 20 minutes and 15 seconds, are you quite sure that shouldn't go into 0.27? |
| [20:54:18] | sphery: | fwiw, the 20min is likely with mysql data and temp on a file system with barriers, and may actually be for those who have innodb tables but who haven't tuned mysql for innodb usage |
| [20:54:54] | sphery: | and since we now specify the engine when creating tables, new users won't get innodb |
| [20:55:27] | sphery: | I'd bet moving mysql temp to a file system without barriers would also cut it from 20min to <2 |
| [20:56:01] | sphery: | but, yeah, putting it in before 0.27 would be fine (and we might as well put that index in, anyway) |
| [20:58:04] | sphery: | would be nice to make it work quickly so users don't worry about it, regardless of how they've configured their systems |
| [21:00:14] | stuartm: | aye, it's such a simple fix from our end and many users won't ever work out that it's a system configuration issue, they'll just blame MythTV |
| [21:00:29] | dekarl: | stuartm, no. But I couldn't make it in time for the original plan. |
| [21:00:29] | stuartm: | and not unfairly too, since we should have an index there |
| [21:02:04] | stuartm: | dekarl: we've not cut the beta yet, and even if we had I very much doubt anyone would object to it going in |
| [21:02:21] | Steve-Goodey (Steve-Goodey!~steve@host86-164-55-78.range86-164.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:03:08] | bobweaver (bobweaver!~bobweaver@unaffiliated/bobweaver) has quit (Quit: Leaving) | |
| [21:03:08] | stuartm: | we are not inflexible about the 'freeze' to the point of excluding bug fixes just because they involve a schema change |
| [21:03:41] | SteveGoodey (SteveGoodey!~steve@host86-164-55-78.range86-164.btcentralplus.com) has quit (Quit: Konversation terminated!) | |
| [21:05:16] | sphery: | and I haven't rolled up the schema initialization to current version, yet, so now's a good time (since I suppose I should do that very soon, now) |
| [21:05:27] | dekarl: | well, should it be a new index or a modification of an existing index? ;) |
| [21:05:36] | sphery: | (so new users don't get a schema then get asked if we can upgrade the schema) |
| [21:05:43] | sphery: | new index |
| [21:06:34] | sphery: | the patch you have (updated for current schema, as required--and with updates for bindings) is fine |
| [21:07:54] | sphery: | if you don't have time, I could plan to do that update, then do the initial schema rollup |
| [21:11:10] | dekarl: | Looking at the referenced commit I'm wondering if title,subtitle,starttime would be a better order of the indexed fields. But I'm not that deep into Mysql optimization. |
| [21:11:50] | dekarl: | http://code.mythtv.org/trac/changeset/bb58a94 . . . 88e1b/mythtv |
| [21:12:26] | gigem: | dekarl: That was my intention, and would make it symmetrical with the programid, starttime index already uesed. |
| [21:14:22] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 246 seconds) | |
| [21:25:34] | dekarl: | hmm, looking at the code make me wonder... why are we using a pointer to the first element instead of the same address but as a pointer to the dynamically sized array? if (!performActualUpdate(&updates[0], "1314", dbver)) |
| [21:37:37] | dekarl: | I hope I've got everything http://code.mythtv.org/trac/attachment/ticket . . . rmance.patch |
| [21:49:57] | gigem: | dekarl: Probably because everyone copies and pastes from the previous entry. Your patch looks fine for the schema update. If our former DBA here at work is to be believed, the SQL JOINs wanting to use the index need to use the same ordering. http://pastebin.com/HcNisWCL should do the trick, but is untested. |
| [21:53:26] | joki (joki!~joki@p54863A52.dip0.t-ipconnect.de) has quit (Ping timeout: 256 seconds) | |
| [21:58:43] | joki (joki!~joki@p548626D9.dip0.t-ipconnect.de) has joined #mythtv | |
| [22:07:14] | sphery: | dekarl: Looks like we started with the &updates[0] stuff in 1303, which was the first of the UTC updates (before that, we just passed in updates and, like gigem said, others copied what was above since danielk's), so since it was danielk, I'm guessing there's some performance reason or something? Would be worth asking him. |
| [22:09:38] | wilm_____ (wilm_____!~wilmoore@vlandnat.mystrotv.com) has joined #mythtv | |
| [22:10:40] | wilmoore-misc (wilmoore-misc!~wilmoore@vlandnat.mystrotv.com) has quit (Ping timeout: 264 seconds) | |
| [22:19:12] | dekarl: | gigem: I couldnt find a reference to the order of fields in the index influencing the join. |
| [22:19:43] | dekarl: | but that is not a schema change and can go in post 0.27 :D |
| [22:23:14] | wilm_____ (wilm_____!~wilmoore@vlandnat.mystrotv.com) has quit (Read error: Operation timed out) | |
| [22:23:21] | wilmoore-misc (wilmoore-misc!~wilmoore@2001:1998:6f1:12:fd8c:d90e:f501:c01e) has joined #mythtv | |
| [22:23:43] | dekarl: | sphery: in 1303/1304/1305 that might be some kind of cast from vector<const char*> to const char*[] |
| [22:25:48] | sphery: | ah, yeah, in there he didn't use a const char* since he was dynamically building the list of SQL instructions |
| [22:26:15] | sphery: | so the others--that actually use the const char *--should probably just pass updates |
| [22:27:24] | sphery: | we can probably leave it as is for now and switch them after 0.27 release |
| [22:27:40] | sphery: | unless others think we should change it now |
| [22:27:52] | sphery: | good catch, btw |
| [22:31:19] | dekarl: | I think it has time. just wondering why the static checkers didnt complain ;) |
| [22:33:58] | dekarl: | hmm, I ran out of hacking time for tonight before I could get the new query explained. I'm happy if anyone gets to look at it and likes to push the last patch from #11282. Or I can look at it again tomorrow |
| [22:33:58] | ** MythLogBot http://code.mythtv.org/trac/ticket/11282 ** | |
| [22:45:01] | NewBuntu81 (NewBuntu81!~NewBuntu8@c-174-55-63-180.hsd1.pa.comcast.net) has joined #mythtv | |
| [22:47:19] | NewBuntu81: | My backend runs mythtv 0.24. One of my frontends needed to be rebuilt, so I installed Mythbuntu 12.04 LTS. However, I am noticing it has mythtv 0.25. Is it possible to downgrade mythtv to 0.24 so it will speak to my backend? I have no intention of upgrading the backend. |
| [22:48:38] | NewBuntu81: | I will also note that the Mythbuntu 12.04 LTS seems to work well with all of my hardware on the frontend, so I really didn't want to have to go back to 11.x series if I could make 12.04 work with mythtv 0.24. Have read many articles but I see only questions, no answers so far. |
| [22:53:38] | gigem: | dekarl: I can't find any reference either. Perhaps it was a SQL Server issue since that's what he used. |
| [23:08:34] | NewBuntu81-2 (NewBuntu81-2!~HVR2250@c-174-55-63-180.hsd1.pa.comcast.net) has joined #mythtv | |
| [23:09:19] | NewBuntu81 (NewBuntu81!~NewBuntu8@c-174-55-63-180.hsd1.pa.comcast.net) has quit (Quit: Leaving) | |
| [23:15:24] | NewBuntu81-2 (NewBuntu81-2!~HVR2250@c-174-55-63-180.hsd1.pa.comcast.net) has quit (Quit: Quitting) | |
| [23:15:39] | NewBuntu81-2 (NewBuntu81-2!~HVR2250@c-174-55-63-180.hsd1.pa.comcast.net) has joined #mythtv | |
| [23:17:15] | Hydr0p0nX (Hydr0p0nX!~hydr@68-190-9-56.dhcp.dctr.al.charter.com) has joined #mythtv | |
| [23:17:31] | Hydr0p0nX (Hydr0p0nX!~hydr@68-190-9-56.dhcp.dctr.al.charter.com) has left #mythtv () | |
| [23:20:05] | NewBuntu81-2: | Does anyone know if you can connect a frontend with mythtv 0.25 to a backend with 0.24? I don't want to upgrade my backend. But the updates in Mythbuntu 12.04 kernel are favorable to my hardware. |
| [23:26:01] | sphery: | NewBuntu81–2: all mythtv components must be the same version (and, if not in the stable -fixes branch--if using development versions--the same revision) |
| [23:26:29] | sphery: | oh, and I think we want #mythtv-users |
| [23:27:26] | NewBuntu81-2: | Thanks Sphery. Sorry, haven't been on here in years. That means everything has worked well for years. :-) Can I downgrade mythtv 0.25 to 0.24 on the 12.04 version? |
| [23:28:41] | IReboot (IReboot!~doug@CPE10bf48e67915-CM78cd8e7e342d.cpe.net.cable.rogers.com) has quit (Quit: Ex-Chat) | |
| [23:51:42] | knightr (knightr!~knight@mythtv/developer/knightr) has quit (Quit: Leaving) | |
| [23:57:55] | knightr (knightr!~knight@mythtv/developer/knightr) has joined #mythtv | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.