| Friday, January 17th, 2014, 00:04 UTC | ||
| [00:04:53] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds) | |
| [01:19:32] | verm__: | should the 'network recorder' be compiled by defaeult? |
| [01:19:35] | verm__: | default? |
| [01:20:07] | verm__: | is it the IPTV recorder? it was renamed? |
| [01:20:41] | wagnerrp: | yes |
| [01:20:54] | verm__: | ah, the image is out dated, thanks |
| [01:24:00] | wagnerrp: | image? |
| [01:24:28] | verm__: | http://www.mythtv.org/wiki/User_Manual:Settin . . . ing_Recorder |
| [01:24:33] | verm__: | 2nd image |
| [01:47:35] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [02:01:26] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Ping timeout: 252 seconds) | |
| [02:09:07] | verm__: | is mythweb still developed or has it been dropped? |
| [02:10:53] | wagnerrp: | the city lights mod is pretty |
| [02:11:12] | wagnerrp: | bah... wrong channel |
| [02:36:21] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!) | |
| [03:13:04] | peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Read error: Operation timed out) | |
| [03:18:22] | peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv | |
| [03:21:26] | nyloc (nyloc!~quassel@p3EE2D288.dip0.t-ipconnect.de) has joined #mythtv | |
| [03:25:51] | _nyloc_ (_nyloc_!~quassel@p3EE2CD2B.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds) | |
| [03:32:26] | arescorpio (arescorpio!~arescorpi@56-57-245-190.fibertel.com.ar) has quit (Excess Flood) | |
| [03:39:04] | tonsofpcs (tonsofpcs!~mythbuntu@cpe-67-255-119-102.stny.res.rr.com) has quit (Changing host) | |
| [03:39:04] | tonsofpcs (tonsofpcs!~mythbuntu@rivendell/member/tonsofpcs) has joined #mythtv | |
| [03:56:51] | whoDat (whoDat!~cal@75.179.59.17) has left #mythtv () | |
| [04:06:50] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds) | |
| [04:08:08] | fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv | |
| [04:10:20] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [04:57:10] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [05:34:11] | jKlaus (jKlaus!~jKlaus@adsl-74-242-210-54.rmo.bellsouth.net) has joined #mythtv | |
| [05:34:15] | jKlaus: | hey guys |
| [05:35:02] | jKlaus: | just to let you know.. things are coming together with my indexedDB webapp ;) |
| [05:46:13] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds) | |
| [06:09:46] | jKlaus: | looking at the program database it seems programid is not a unquie key |
| [06:10:13] | jKlaus: | what is the unique key? |
| [06:11:08] | dekarl: | jKlaus: channel id + start time |
| [06:12:08] | jKlaus: | dekarl, out of curiosity why no real primary key? |
| [06:13:21] | jKlaus: | I mean I guess I could make my own.. but I really don't like the idea of that |
| [06:14:46] | dekarl: | jKlaus: Maybe folklore? I don't know. Maybe because it is easy to understand? (Which I find more and more important with every year. Developer's time is the one scarce ressource, so we have to make the most from it) |
| [06:15:12] | dekarl: | I think http://code.mythtv.org/trac/wiki/TaskRecordedFile might add some real primary keys around video file / recording (channel id + start time again) primary keys |
| [06:15:22] | jKlaus: | Yes but then you could handle adding to be recorded easier |
| [06:15:38] | dekarl: | How does it make it easier? |
| [06:15:40] | jKlaus: | it could just reference the unique program showing |
| [06:16:10] | dekarl: | But that's super boring... The magic of MythTV is everything but unique program recording :D |
| [06:16:15] | jKlaus: | right now it looks like the 'program' is essentially being recreated |
| [06:16:41] | jKlaus: | But that's the way the rest of the world interacts with relational data ;) |
| [06:17:18] | dekarl: | jKlaus: notice that you may have createted a recording rule 10 years ago and still be recording new upcoming episodes with that old rule, while the guide data is long gone. |
| [06:17:51] | jKlaus: | well you're keying off the programID for that right? |
| [06:18:06] | dekarl: | No, there is no programid for most of the world |
| [06:18:22] | jKlaus: | hmm |
| [06:18:29] | dekarl: | If you have it and it works that can be used for series link and or duplicate detection. |
| [06:19:07] | jKlaus: | I need to spend more time looking over the schema.. I think we could make this better though |
| [06:19:24] | dekarl: | series link referring to finding candidates to record (regardless of having a different title for matches and the same title for non-matches) while duplicate detection relates to well detection which showings are the same |
| [06:19:31] | jKlaus: | Everyone seems to be focused on the UI.. that's fine, I like the backend more lol |
| [06:20:16] | dekarl: | but you have to be aware that most guide data is, well, utter crap |
| [06:21:00] | jKlaus: | What do you mean? The data that gets populated into the guide data or the guide data as a whole.. structure included |
| [06:21:23] | dekarl: | our users can get good data for US/UK TV but that's about it |
| [06:21:52] | jKlaus: | Yeah, do most pull EIT? |
| [06:21:55] | dekarl: | the guide data structure, too. But that's an upstream problem that can only be solved with lots of work |
| [06:22:49] | dekarl: | MythTV is the leader of the pack for most of the DVR aspects, but there is still lots of room for improvement |
| [06:23:11] | jKlaus: | I haven't looked at any of the methods that consume the databases.. I hope there are legitimate business objects created |
| [06:23:13] | dekarl: | For DVB countries yes, many use EIT |
| [06:24:02] | dekarl: | btw, smolt is MIA, if its back you can look at the market share of the various guide sources at http://smolt.mythtv.org/static/stats/stats.html |
| [06:24:45] | jKlaus: | hmm |
| [06:24:57] | dekarl: | no "hubot kick smolt" around here :( |
| [06:25:05] | jKlaus: | so in countries without EIT, where do most get their guide data? |
| [06:26:05] | dekarl: | there is schedules direct for US/CA and various providers that can be accessed via a XMLTV grabber |
| [06:26:27] | jKlaus: | Is there a mythtv solution for any IDE that is used by many or does everyone just use their own IDE |
| [06:26:36] | dekarl: | there is also XMLTV scrapers but I think they should just be sent to the big hard disk in the sky :) |
| [06:27:17] | dekarl: | I think everyone uses their own. But I've heard reports of the main MacOSX/Windows IDE being used, also Eclipse |
| [06:28:08] | jKlaus: | I'm struggling to like Eclipse.. I'm using MonoDevelop but I don't love it either. |
| [06:28:46] | dekarl: | got to leave for work, see you around. (/me is using good old vi and make :D |
| [06:28:47] | jKlaus: | As much as I hate it I've really gotten spoiled by C# in Visual Studio.. it really is a great combination. I hate that working in the M$ world has caused me to say such things |
| [06:29:09] | jKlaus: | haha I like having an integrated git client |
| [06:30:31] | dekarl: | Bah, I have to help our student with his c# assignments... I'm not wondering about the crappyness of windows programs anymore... |
| [06:31:05] | dekarl: | Someone should just hook the windows stuff into the Eclipse IDE properly |
| [06:35:52] | jKlaus: | dekarl, your student? |
| [06:36:36] | jKlaus: | is our the household and student a child? lol |
| [06:38:02] | jKlaus: | well sir, I'm out of here .. heading toward 2a |
| [06:38:04] | jKlaus: | am* |
| [06:41:19] | jKlaus: | dekarl, can you tell me one thing. How do they handle if an update comes in from the guide data source? Say a channel's airing ends up delayed by 15 minutes due to an overtime. When we pull guide data do we remove all existing guide data and replace or only supplement? |
| [06:42:30] | jKlaus: | PM me if you don't mind. |
| [07:08:31] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [07:12:12] | stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has joined #mythtv | |
| [07:12:13] | stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Changing host) | |
| [07:12:14] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [08:08:22] | rsiebert (rsiebert!~quassel@f052148066.adsl.alicedsl.de) has quit (Ping timeout: 252 seconds) | |
| [08:16:10] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv | |
| [08:19:03] | joki (joki!~joki@p54863452.dip0.t-ipconnect.de) has quit (Ping timeout: 276 seconds) | |
| [08:23:11] | joki (joki!~joki@p54862474.dip0.t-ipconnect.de) has joined #mythtv | |
| [08:30:10] | Xplic1T (Xplic1T!4c5d97a0@gateway/web/freenode/ip.76.93.151.160) has joined #mythtv | |
| [08:30:22] | Xplic1T: | im having issues with my hdpvr |
| [08:30:34] | Xplic1T: | anybody have one that can help me out real quick |
| [08:39:23] | Xplic1T (Xplic1T!4c5d97a0@gateway/web/freenode/ip.76.93.151.160) has quit (Ping timeout: 272 seconds) | |
| [08:45:34] | len_ (len_!~quassel@65-128-250-67.mpls.qwest.net) has quit (Read error: Connection reset by peer) | |
| [09:02:20] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [09:21:09] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warped_) | |
| [09:29:09] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [09:29:38] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Client Quit) | |
| [09:36:39] | Warlord (Warlord!warlord@unaffiliated/warlord) has quit (Quit: ZNC - http://znc.in) | |
| [09:44:32] | xris (xris!~xris@mythtv/developer/xris) has quit (Ping timeout: 252 seconds) | |
| [09:51:57] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:e82b:f4be:594f:afe5) has joined #mythtv | |
| [10:39:15] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Ping timeout: 252 seconds) | |
| [10:40:31] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has joined #mythtv | |
| [10:52:36] | xris (xris!~xris@xris.forevermore.net) has joined #mythtv | |
| [11:15:45] | stuartm: | if there are no objections, I'm going to change the trac config to make the login cookie persist across browser sessions – I'm fed up of having to login in again each time I restart the browser |
| [11:16:23] | stuartm: | this will mean you'll have to remember to logout if you're on a public or shared computer |
| [11:17:45] | Merlin83b: | A lot of places that do that have a checkbox to adjust the cookie time, or at least a note saying what's going to happen. Probably the friendliest way to do it :) |
| [11:20:15] | stuartm: | I can't change what Trac offers, just change the configuration |
| [11:20:38] | stuartm: | in practice I don't think it will matter at all |
| [11:20:39] | Merlin83b: | I'm sure they'd welcome a patch ;) |
| [11:22:00] | Merlin83b: | It's a long time since I configured a trac install. I'm sure you're right that it won't really matter. If there's scope for putting a note in saying remember to log out, your session cookie will persist then I think that would be good to add. |
| [11:43:59] | stuartm: | since I accidentally deleted the list I had been making of requests from other developers I've gone ahead and created a dev wiki page to track WebFrontend 'wishlist' items – http://code.mythtv.org/trac/wiki/WebFrontendWishlist |
| [11:45:28] | stuartm: | the dev wiki to stop it becoming inundated by unrealistic (or obtuse) requests (figure devs have a better grasp of what is or isn't realistic) |
| [12:27:10] | TheCrasher (TheCrasher!~TheCrashe@p5DCE4DEF.dip0.t-ipconnect.de) has joined #mythtv | |
| [13:04:12] | stuarta: | afternoon |
| [13:17:01] | Fearful_ (Fearful_!~warlord@core.dumped.at.gshellz.org) has joined #mythtv | |
| [13:48:02] | amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv | |
| [14:04:01] | stuarta: | verm__: did you run into any linking errors in external/nzmqt?? |
| [14:10:03] | jklaus_ (jklaus_!~jklaus@2600:1004:b01e:5ce6:b858:b0ba:ed79:7df5) has joined #mythtv | |
| [14:10:31] | jklaus_ is now known as jKlaus_work | |
| [14:10:36] | jKlaus_work: | Hey guys |
| [14:13:36] | jKlaus_work: | I thought about some of the table schema last night and I'm thinking about working on a fairly large restructuring. Would anyone contest to such a thing? |
| [14:14:20] | jKlaus_work: | I really feel like we should have a 'Program' table and something to the effect of an 'Airing' table. |
| [14:14:20] | zentec: | I support such a thing |
| [14:14:47] | zentec: | and I say that from my comfy position on the periphery of development |
| [14:14:54] | jKlaus_work: | Program table containing unique programs only.. ie the programid would become the primary key |
| [14:15:03] | jKlaus_work: | lol |
| [14:15:04] | zentec: | ^that |
| [14:15:41] | jKlaus_work: | Then we'd have to create a primary key for airing data.. would most likely just be an autogenerated id |
| [14:15:45] | stuarta: | jKlaus_work: what problem are you trying to solve by that? |
| [14:16:19] | jKlaus_work: | Our data just isn't structured well. It could be done much better |
| [14:16:43] | jKlaus_work: | This data is heavily relational and its not built in a relational mannor |
| [14:17:16] | stuarta: | yeah, there are definitely some areas that need work |
| [14:17:25] | jKlaus_work: | I'm an odd ball, I'd rather work on the infrastructure than the look and feel |
| [14:17:41] | jKlaus_work: | not much of a UX guy.. but I'm good with data lol |
| [14:17:42] | stuarta: | no you aren't, i'm exactly the same. |
| [14:18:05] | stuarta: | which is why i do EIT and buildbots :) |
| [14:18:41] | jKlaus_work: | I do have a question though.. how does the program data get populated? Does it clear out the DB every time it syncs with a source? |
| [14:19:05] | stuarta: | EIT does incremental updates |
| [14:19:18] | stuarta: | not quite sure about how mythfilldatabase does it's work |
| [14:19:35] | jKlaus_work: | How exactly does that work if the time of programming shifts by say 15 minutes due to an overtime |
| [14:20:17] | jKlaus_work: | I mean it wouldn't be easy to relate back to a primary key over the current method either. |
| [14:20:19] | stuarta: | in practice they rarely change the data |
| [14:20:43] | jKlaus_work: | During the fall the NFL screws up stuff left and right lol |
| [14:22:03] | zentec: | I don't know if there is an easy fix for that |
| [14:22:13] | jKlaus_work: | I have an idea.. |
| [14:22:48] | zentec: | the dirty secret about EIT in ATSC in the US is...most stations use Triveni PSIP encoders and the device pulls guide data from Triveni via FTP, and it's the *same* source as schedulesdirect.org |
| [14:23:12] | jKlaus_work: | you look in the 'airing' table, starting at the time/channel coming in from your source you look above and below that time by 1 minute per iteration |
| [14:23:24] | jKlaus_work: | iterate until you find that channel |
| [14:23:25] | zentec: | and I don't see how stations would be able to update quickly enough to make a difference |
| [14:23:28] | stuarta: | the data isn't that dynamic |
| [14:23:41] | jKlaus_work: | get the airing id and adjust the time accordingly |
| [14:23:55] | stuarta: | the broadcaster rarely update the data to be correct in the event of an overrunning sport program |
| [14:24:00] | jKlaus_work: | That's phase 2 of my master plan lol |
| [14:24:15] | jKlaus_work: | Doesn't the EIT data update? |
| [14:24:27] | stuarta: | if the broadcaster does, then yes |
| [14:24:41] | stuarta: | if they push it, we'll pick it up |
| [14:24:46] | zentec: | I can attest, local affiliates don't worry about |
| [14:24:47] | jKlaus_work: | so how does the EIT data suppliment a source like schedules direct? |
| [14:24:57] | stuarta: | mutually exclusive |
| [14:25:32] | stuarta: | there's too much disparity in the data even for the same episode |
| [14:25:41] | jKlaus_work: | bah, I think the EIT data should be able to 'update' the schedules direct data |
| [14:25:43] | stuarta: | which throws the scheduling out to hell |
| [14:25:43] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit () | |
| [14:26:03] | jKlaus_work: | well you get the channel and time well enough don't you? |
| [14:26:07] | jKlaus_work: | from EIT |
| [14:26:11] | stuarta: | yes |
| [14:26:21] | jKlaus_work: | I'd be fine with making the assumption that its airing the same program |
| [14:26:27] | stuarta: | and title |
| [14:26:37] | jKlaus_work: | program.title .. |
| [14:26:51] | jKlaus_work: | class program { title {get;set;}} |
| [14:27:00] | stuarta: | at least for dvb there is no subtitle in the raw eit data, we have to make it from the description |
| [14:27:14] | jKlaus_work: | you don't need to worry about updating the actual program info |
| [14:27:25] | jKlaus_work: | I'm talking about just updating the airing times |
| [14:27:40] | jKlaus_work: | crap g2g, meeting at 9:30 |
| [14:27:44] | stuarta: | theoretically possible, but needs work |
| [14:27:48] | jKlaus_work: | I'm in EST if you were wondering |
| [14:27:59] | stuarta: | guessed that |
| [14:28:05] | jKlaus_work: | stuarta.. and I'm willing to do such work ;) |
| [14:34:12] | gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv | |
| [14:38:20] | jKlaus_work: | man.. this bites |
| [14:38:43] | jKlaus_work: | I just met with a user to go over some issues they had with software my company (different office) wrote for them last year |
| [14:38:57] | jKlaus_work: | this shit is all in javascript and its all done differently |
| [14:49:01] | Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:e82b:f4be:594f:afe5) has quit (Quit: Leaving) | |
| [14:53:44] | sphery: | jKlaus_work: there's already a plan for a huge refactor of the tv and video data schemas |
| [14:54:51] | jKlaus_work: | When does that work kick off – is there a schema designed yet? Is the creator open to other's reviewing/commenting. |
| [14:55:16] | sphery: | the link that de karl (I think) gave to you is to an older version of the schema design--I haven't had a chance to update it |
| [14:55:37] | jKlaus_work: | ok |
| [14:55:46] | jKlaus_work: | Please tell me we are making things more relational ;) |
| [14:56:00] | sphery: | once it's done, it will probably result in changes to the program table, too, but they will come after we see what happens with the changes to the recorded/video stuff |
| [14:56:31] | jKlaus_work: | I really think we need to revise how the program table is structured |
| [14:56:34] | sphery: | and may come much later as much of our code/protocol/... is based around the current design of program table |
| [14:56:46] | jKlaus_work: | yeah |
| [14:57:11] | jKlaus_work: | It would require having the new schema running beside the old schema for a while |
| [14:57:19] | jKlaus_work: | we're doing that at work right now lol |
| [14:57:20] | sphery: | so we may not get to changing program until after we've switched to a new protocol and, ideally, moved the DB to all internal with only one process ever accessing it directly (such that it becomes the mythdataserver) |
| [14:57:45] | jKlaus_work: | yeah |
| [14:58:00] | jKlaus_work: | Do you do any UML diagrams? |
| [14:58:42] | sphery: | but we don't necessarily want to normalize the database /too/ much--as it is, many users are trying to run MythTV and the MySQL server on severely underpowered systems that can't do what MythTV asks of them with reasonable performance |
| [14:58:50] | jKlaus_work: | I could start putting something together given the new structure if you guys need a hand. Though we recently bought a house and I have a hand full of projects which will be starting off in the spring |
| [14:59:51] | jKlaus_work: | very understandable but what I'm thinking of for the program table woudln't impact load all too much |
| [14:59:54] | sphery: | so we don't want to make things much more complex/slower--especially since storage is cheap (at least on a system designed to store multi-gigabyte recording files, you should be able to come up with a couple hundred megabytes for data |
| [15:00:29] | sphery: | also, the biggest problem with your proposal is identifying which is the same program |
| [15:00:50] | jKlaus_work: | Yeah but you're really not talking about requiring much CPU for a lot of this. |
| [15:00:53] | sphery: | throughout the world, there's no standard approach for identifying exactly what's the same |
| [15:01:30] | jKlaus_work: | Currently we have a 'program' which contains program information (title, subtitle, blah blah blah, programID) |
| [15:01:33] | sphery: | we have a system that works well enough for "record all", but is not ideal for "let's throw away this program and say that the other is the same" |
| [15:01:56] | sphery: | programid is listings-service dependent |
| [15:01:58] | jKlaus_work: | and it also contains the airing information – channel (ID) and time |
| [15:02:02] | sphery: | it's provided by Schedules Direct |
| [15:02:45] | sphery: | we make one for XMLTV users iff they get a reported season number and episode by hashing the title and appending season/episode # |
| [15:03:20] | jKlaus_work: | It doesn't matter what the programid is so long as it is unique per program |
| [15:03:37] | sphery: | and some xmltv systems provide it, but are using other approaches (some of which are even less certain than our way of faking it) |
| [15:03:38] | stuartm: | jKlaus_work: he's saying that there's not guaranteed to be a programid |
| [15:03:45] | sphery: | so it's not trustworthy |
| [15:03:59] | stuartm: | it's not available for a large percentage of users |
| [15:04:23] | jKlaus_work: | You don't necessarily need to use the programid as the primary key though |
| [15:04:32] | jKlaus_work: | it could just be one of the indexes on the table |
| [15:04:47] | jKlaus_work: | you could create an autogenerated id to act as the primary key |
| [15:05:03] | sphery: | and channel id and time can change--we have some EIT users whose program starts change by anywhere from seconds to minutes over the course of initial reporting until broadcast |
| [15:05:30] | jKlaus_work: | by default have it resolve the program via the programid, if null then use whatever alternate process is currently in place.. I assume title matching? |
| [15:05:35] | sphery: | we will have an autoincrement ID, eventually |
| [15:06:37] | sphery: | but I'd only want us to have content vs airing information separate if the guide source provides it that way--i.e. I don't like the idea of us just deciding that "it's the same, so I'll throw out the other info" |
| [15:06:46] | stuartm: | there are different matching methods, e.g. Title + Subtitle, or Title + Description |
| [15:06:57] | sphery: | and just to save a few 10s of kB or so |
| [15:07:06] | jKlaus_work: | yah I assume stuartm |
| [15:07:29] | jKlaus_work: | its not just that sphery.. there is a reason why relational data is stored in a relational db |
| [15:07:46] | sphery: | and those duplicate matching behaviors are specified per recording rule because even in a given area, the same dup match method may not apply across all sources/channels/programs |
| [15:09:10] | sphery: | so unless we force every user to figure out what method to use for duplicate matching for each program in their entire listings set, we'd have to be making assumptions (which is very dangerous compared to just storing what we're given and letting the user make decisions when setting up recording rules if the program is important to them) |
| [15:09:52] | jKlaus_work: | I'm doing all of this kind of stuff for work right now |
| [15:10:27] | jKlaus_work: | Its SQL and C# but that's the only real difference |
| [15:11:49] | sphery: | well, I'd suggest trying to work with our--admittedly ugly--current schema for now and see how things look when we get the first round of schema changes done--those that affect the actual recordings/product for MythTV |
| [15:12:36] | jKlaus_work: | but the program information should be used for recorded and torecord type information |
| [15:12:45] | sphery: | after that, we'll be more interested in making changes to listings schema (data used to find the shows to record, else just temporary data) |
| [15:13:06] | jKlaus_work: | right now we duplicate data all over the place |
| [15:13:28] | sphery: | right, but we do so because it's safer than deciding what makes for "the same" data |
| [15:13:45] | jKlaus_work: | Not the duplications I'm talking about |
| [15:13:48] | sphery: | especially when you consider the vast quality differences in listings data for users around the world |
| [15:14:08] | jKlaus_work: | for instance.. we have a 'program to air' and a 'program that has been recorded' |
| [15:14:15] | sphery: | (where listings data quality is probably the biggest issue for most users) |
| [15:14:23] | jKlaus_work: | those should both be relational, tied back to 'a program' |
| [15:15:13] | jKlaus_work: | there's no sense in copying half of the data from a 'program to air' to a 'program that has been recorded' |
| [15:15:27] | sphery: | we have a row in program that shows the program listing before it airs and, if we record that, we move the part of the data we keep to a couple other tables, and then 2 weeks after airing, we delete the listings data |
| [15:16:03] | jKlaus_work: | yes, but if you had a true 'program' you'd just copy its primary key |
| [15:16:10] | sphery: | so that duplication exists for at most 2 weeks |
| [15:16:39] | FabriceMG (FabriceMG!~Thunderbi@LCaen-156-54-30-212.w80-11.abo.wanadoo.fr) has quit (Quit: FabriceMG) | |
| [15:17:05] | jKlaus_work: | You're never going to convince me that that is good data management |
| [15:17:42] | sphery: | I'm not trying to--just trying to say it's not /that bad/ for our purposes, for now |
| [15:18:15] | sphery: | but the first round of changes will be changing things quite a bit |
| [15:18:29] | jKlaus_work: | That's fine.. I'm willing to do the leg work |
| [15:18:51] | jKlaus_work: | or finger work as it were |
| [15:18:59] | sphery: | we'll still have a different location for storing metadata for recorded shows vs listings data, but we're also going to store things in a very different approach |
| [15:19:17] | jKlaus_work: | I'm not expecting to figure this out over night. I'm just saying that I'm going to start looking into it |
| [15:19:30] | sphery: | because we'll be sharing the same table design for recordings and non-recorded, user-managed videos (Video Library videos) |
| [15:20:30] | stuartm: | http://code.mythtv.org/trac/ticket/12023#comment:1 &ndas h; Sorry, but I'd dispute that |
| [15:20:36] | sphery: | and we want data in a format that will make integration of the 2 libraries of video (recorded and user-provided) easy |
| [15:21:17] | sphery: | stuartm: that's how it was designed |
| [15:21:26] | jKlaus_work: | I understand that. Like I said, I'm not expecting this to happen over night – nor am I expecting you to do it. |
| [15:21:33] | jKlaus_work: | I'm saying I can get started on it |
| [15:21:36] | sphery: | the fact that users abuse it for a poor-man's soft padding approach is another story |
| [15:21:58] | jKlaus_work: | I just want to know that if I do it and it works out, that it will eventually be integrated and I won't be wasting my time and have to maintain my own fork |
| [15:22:05] | sphery: | stuartm: and, really, the fact that the multirec design is broken is the reason it doesn't work the way the user wants |
| [15:22:07] | stuartm: | sphery: if that were the case, why the end padding setting? |
| [15:23:17] | sphery: | stuartm: if they'd have designed multirec such that there was exactly one card and multiple virtual inputs (rather than virtual cards, which is completely different from how other recorders work), it would actually use the global values on each input |
| [15:23:25] | sphery: | I'm assuming for symmetry |
| [15:23:42] | stuartm: | jKlaus_work: if a change is going to be as invasive and disruptive as the one you're proposing, then it needs to have a significant and tangible benefit, otherwise it just causes major disruption and obscure bugs that can take months to put right |
| [15:23:58] | sphery: | jKlaus_work: all I can say is that we have a very specific design in mind that we'll be working on as we get time |
| [15:24:00] | stuartm: | "if it ain't broke, don't fix it" |
| [15:24:14] | sphery: | and that's a good point, too |
| [15:26:11] | jKlaus_work: | Once again.. I would get it to a point where it'd be a seemless transition before ever bringing it public |
| [15:26:21] | jKlaus_work: | Once again, I do this for a living |
| [15:26:32] | jKlaus_work: | On far more complicated systems than mythtv |
| [15:27:15] | stuarta: | sphery: stuartm i do think if people are volunteering to help they should be encouraged not discouraged |
| [15:27:25] | jKlaus_work: | ^ |
| [15:30:03] | stuartm: | stuarta: I encourage people all the time, but I generally suggest that they start with something smaller than a full scale refactor – not only so that they might get to know the code and the reasons why it works the way it does, but also so that we might get to know them and their work in easy to review chunks |
| [15:31:30] | stuartm: | I've seen way too many people appear from nowhere with huge, difficult to review patches which when they finally do get committed cause as their share of problems which the core dev team has to fix because the patch author has vanished again |
| [15:32:09] | jKlaus_work: | I understand that – but lead with that. |
| [15:34:58] | jKlaus_work: | There was a guy at this client's that took a dogmatic stance on "Don't touch it if it works". Now the client is having all kinds of issues trying to make things 'modern'. |
| [15:35:32] | jKlaus_work: | They have so much crap going on it store procedures they have no idea what anything really does or where to find it b/c there's little to no documentation |
| [15:36:42] | jKlaus_work: | So now we're creating a fairly parallel database and migrating tables as we go, building DTOs via webservices |
| [15:43:01] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds) | |
| [15:46:56] | jKlaus_work: | Are there any existing UML diagrams that reflect the DB schema? |
| [15:47:04] | jKlaus_work: | or any other diagrams? |
| [15:50:41] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [15:51:51] | dekarl_ (dekarl_!51c8c614@gateway/web/freenode/ip.81.200.198.20) has joined #mythtv | |
| [15:52:18] | dekarl_: | jKlaus_work: if you fancy a database schema challange in the program guide domain then I can help you :D |
| [15:53:01] | jKlaus_work: | haha |
| [15:53:10] | dekarl_: | the one big missing building block is a metadata site with a data model that is complex enough to model the usual tv programmes around the world. I can send you user stories that want to be modelled in a complexity like http://musicbrainz.org/doc/MusicBrainz_Database/Schema |
| [15:53:12] | jKlaus_work: | pm me details – have to run to a meeting. |
| [15:56:04] | dekarl_: | stuff like "a person A performed as character B in movie C" with details like "the characters visual appearence is based on person D" (for CGI) and "the characters movements are performed by person E" (for motion capture) and "the voice in the first german release was dubbed by person |
| [15:56:31] | dekarl_: | "stunts of the character were done by person G" and so on |
| [15:58:50] | dekarl_: | or "this series is set in series universe A which as derived from the real world". |
| [15:59:38] | dekarl_ (dekarl_!51c8c614@gateway/web/freenode/ip.81.200.198.20) has quit (Quit: going home for the weekend, see you around) | |
| [16:35:45] | dekarl1 (dekarl1!~dekarl@p4FE84D6E.dip0.t-ipconnect.de) has joined #mythtv | |
| [16:36:11] | dekarl (dekarl!~dekarl@p4FE8468D.dip0.t-ipconnect.de) has quit (Ping timeout: 253 seconds) | |
| [16:52:29] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has joined #mythtv | |
| [16:55:41] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:11:31] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has joined #mythtv | |
| [17:11:31] | NightMonkey (NightMonkey!~NightrMon@173-164-139-193-SFBA.hfc.comcastbusiness.net) has quit (Changing host) | |
| [17:11:32] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [17:16:21] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds) | |
| [17:20:15] | mrand (mrand!~mrand@ubuntu/member/mrand) has quit (Ping timeout: 272 seconds) | |
| [17:20:53] | sphery (sphery!~mdean@mythtv/developer/sphery) has quit (Ping timeout: 272 seconds) | |
| [17:20:53] | mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv | |
| [17:21:09] | sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv | |
| [17:32:09] | dekarl1 is now known as dekarl | |
| [17:51:45] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Remote host closed the connection) | |
| [17:53:30] | jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv | |
| [17:54:17] | stichnot (stichnot!~stichnot@216.239.45.80) has joined #mythtv | |
| [17:54:17] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [17:54:17] | stichnot (stichnot!~stichnot@216.239.45.80) has quit (Changing host) | |
| [17:56:43] | natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv | |
| [18:17:29] | xris (xris!~xris@xris.forevermore.net) has quit (Changing host) | |
| [18:17:29] | xris (xris!~xris@mythtv/developer/xris) has joined #mythtv | |
| [18:21:40] | rsiebert (rsiebert!~quassel@f052148066.adsl.alicedsl.de) has joined #mythtv | |
| [18:29:26] | stichnot (stichnot!~stichnot@216.239.45.80) has joined #mythtv | |
| [18:29:26] | stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv | |
| [18:29:26] | stichnot (stichnot!~stichnot@216.239.45.80) has quit (Changing host) | |
| [19:41:55] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [20:10:26] | warped_: | evening all. Just short update regarding my yesterday's investigations concurrent recording reliability. Current 0.27 works OK. Issue was duration of scheduled tests. It was 1min and as 16 recorders are kicked in the same time – last of them were starting after time longer than minute. IIRC now SM monitor is active during whole recording period – some recordings have tear-down SM before SM thread receives CPU shares to handle DVB tables. SM |
| [20:10:27] | warped_: | timeouts and rec. becomes failed. |
| [20:12:54] | warped_: | BTW: 0.27 seems to be pretty effective for disk writing: 16xHD streams needs 35–38% of single core on i3. HDD has 17–20k IOPS and no any TFW writer warnings. With 16 xHD streams, writer warnings can be triggered by i.e. asking MythWeb for listing 2k recordings. |
| [20:15:49] | Lomion0815 (Lomion0815!~chatzilla@188-23-194-100.adsl.highway.telekom.at) has joined #mythtv | |
| [20:21:48] | Lomion0815: | @wagnerrp: I added a comment to #12023 describing in more detail the problem I saw. I believe the bug report is valid. |
| [20:21:48] | ** MythLogBot http://code.mythtv.org/trac/ticket/12023 ** | |
| [20:33:59] | wagnerrp_ (wagnerrp_!4084ae8b@gateway/web/freenode/session) has joined #mythtv | |
| [20:34:41] | wagnerrp_: | stuartm: is that ticket not about the hardware soft padding? |
| [20:36:34] | wagnerrp_ (wagnerrp_!4084ae8b@gateway/web/freenode/session) has quit (Changing host) | |
| [20:36:34] | wagnerrp_ (wagnerrp_!4084ae8b@gateway/web/freenode/ip.64.132.174.139) has joined #mythtv | |
| [20:37:20] | stuartm: | wagnerrp_: it's about whether it should or shouldn't be used the way pretty much _everyone_ has been using it for the last 10 years – I've no idea when our position on this changed, but it was always the advice given on IRC (never read the mailing list much) that the 'global' padding feature was to allow some room for schedulers starting or ending programs early/late |
| [20:40:13] | stuartm: | what would have been the logic behind adding the global 'End Late' setting if the global padding was only to allow for devices which took time to warm up? |
| [20:40:34] | SteveGoodey (SteveGoodey!~SteveGood@host109-158-212-221.range109-158.btcentralplus.com) has joined #mythtv | |
| [20:40:46] | wagnerrp_: | never did see the purpose of the "end late" option |
| [20:40:50] | stuartm: | it's a version of history I don't personally recognise |
| [20:41:03] | wagnerrp_: | for years, i wondered why no one ever removed it |
| [20:41:55] | stuartm: | it was there to serve as soft padding, and it does that very well, as does the start early setting |
| [20:43:04] | stuartm: | so even if it means changing the purpose of the settings (to what everyone always believed) then that's what I'll do :) |
| [20:43:56] | sphery: | stuartm: fwiw, that patch looks broken |
| [20:44:24] | stuartm: | sphery: noted |
| [20:45:44] | sphery: | (meaning just because it's the same multiplex doesn't mean it's not busy--we may need all available virtual tuners for other recordings in progress or starting up) |
| [20:45:59] | sphery: | or "won't be busy" |
| [20:47:02] | sphery: | I still think we should do as gigem mentioned, and remove the "Time to record before/past start/end of show (secs)" and teach people to use per-rule start early/end late, so they get padding when they ask for it |
| [20:47:38] | stuartm: | I'll fight to the death for soft padding |
| [20:47:41] | sphery: | and put in a reasonable default |
| [20:48:43] | stuartm: | the per-rule setting causes unacceptable conflicts – I'd sooner lose 30 seconds off the start of a program than not have it, or the recording before it not be recorded at all |
| [20:48:54] | sphery: | I still believe you're getting (and will get even if you change it to use soft padding + multirec) that soft padding far less often than you would want |
| [20:49:37] | stuartm: | all we're saying with the 'soft' padding is to try, only if it won't cause a conflict, to allow some margin for error in the broadcast time vs scheduled time |
| [20:49:47] | sphery: | have you tried the per-rule setting to see how many conflicts you get? |
| [20:49:55] | sphery: | with multirec, you probably get very few ever |
| [20:50:06] | wagnerrp_: | implement soft padding as an option in the recording rule |
| [20:50:07] | stuartm: | sphery: it's worked perfectly fine for me for years, and others I might add |
| [20:50:29] | sphery: | anyway, it will be a lot of work to make a safe patch (that doesn't screw up other recordings) for /very/ little benefit |
| [20:50:32] | wagnerrp_: | default to hard padding, allow soft padding to be selected, or used as a specific show override |
| [20:50:33] | Lomion0815: | The advantage with the soft padding that it still works with back-to-back recording while the settings in the recording rule does not /automatically |
| [20:50:48] | stuartm: | wagnerrp_: that's another option, but I don't see the sense in removing one until a valid alternative is in place |
| [20:51:07] | sphery: | Lomion0815: the per-rule values work /always/ work with back to back recordings, and global ones /never/ do |
| [20:51:11] | wagnerrp_: | Lomion0815: that's the whole point, with hard padding the scheduler goes and finds another showing |
| [20:51:15] | sphery: | and btw, it's not called "soft padding" |
| [20:51:18] | sphery: | soft padding doesn't work |
| [20:51:41] | sphery: | See all 5 pages of http://www.gossamer-threads.com/lists/mythtv/dev/195124 for why |
| [20:51:50] | wagnerrp_: | sphery: presumably he means back-to-back on different channels |
| [20:52:01] | sphery: | and feel free to check out the branch that was created that implemented soft padding and figured out that it doesn't work |
| [20:52:38] | sphery: | Lomion0815: what you're saying is "the global time to record before/past... settings are ignored for back-to-back recordings so I don't get conflicts when I don't have sufficient tuners available" |
| [20:52:55] | sphery: | IMHO, that's a /terrible/ way of getting padding because then you get /no/ padding on either show |
| [20:53:40] | sphery: | so if a) one is a good show and the other is "just in case" and the good show /needs/ that last 2 minutes, you miss it and get garbage "just in case" that you probably would rather have missed to get the proper ending to the good show |
| [20:53:56] | sphery: | and if a) both are good and both need the padding, you've messed up 2 recordings |
| [20:54:33] | stuartm: | I'm really sorry guys, but I can't really see where you're coming from on this – the soft padding is widely used and for most people it works exactly as they want, you seem to be implying the exact opposite – that hard padding and conflicts is what everyone actually wants by default – possibly true for Australia where schedules are systematically wrong, but the rest of us just want some leeway for broadcasters who fudge the timings by upto a |
| [20:54:35] | stuartm: | minute on a handful of programs to keep the schedules otherwise on time |
| [20:54:39] | sphery: | and if c) both are good but the beginning of the 2nd is far less important than the end of the first, you missed the end of the first and got a boring intro to the 2nd |
| [20:54:41] | sphery: | and ... |
| [20:54:56] | sphery: | but if z) both don't need the padding that much, you got the right thing |
| [20:55:42] | sphery: | but since you weren't told that there's a conflict, /you/ didn't decide and you got no overrecord on either--so one case out of however many works out right |
| [20:57:41] | stuartm: | the problem with conflicting so regularly is that it then requires micro-managing your recording schedules, imposing override rules just to get things to work right for a given week etc, with the soft padding I don't even have to check for conflicts very often and that's the way I prefer it |
| [20:57:56] | wagnerrp_: | that's my belief. if i'm getting overruns such that i need padding, i'd rather have assurance that that padding i configured would actually be applied, or get a warning ahead of time otherwise |
| [20:58:01] | sphery: | stuartm: what I'm saying is simply that we have a mechanism by which users can specify when extra time is important and when it's not, and it generally works without conflict for users with multirec--which is the only case #12023 is trying to change |
| [20:58:01] | ** MythLogBot http://code.mythtv.org/trac/ticket/12023 ** | |
| [20:58:17] | Lomion0815: | In fact it's simple ... avoid overlappings where possible (taking the "soft padding" in account) and record back-to-back no reschedule is possible ... |
| [20:58:23] | stuartm: | sphery: we DO have a mechanism, the recording priority :) |
| [20:58:48] | sphery: | and when it does present a conflict, the /user/ gets to decide what to do and set an appropriate override rule to allow that |
| [20:59:02] | wagnerrp_: | stuartm: recording priority will not tell the scheduler to apply soft padding at the detriment of the lower ranked show |
| [20:59:12] | stuartm: | but that's to miss the point, people are happy with the way it works now – why drop the feature for the sake of 'perfection' |
| [20:59:48] | stuartm: | wagnerrp_: it doesn't now, it could, if we wanted to and improve the feature (but I don't think it needs improving) |
| [21:00:38] | stuartm: | to repeat something that used to be quoted often in this channel "perfect is the enemy of good" |
| [21:01:16] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Quit: warped_) | |
| [21:01:34] | stuartm: | to drop soft padding would be to the detriment of MythTV, not the opposite |
| [21:02:02] | Fearful_ (Fearful_!~warlord@core.dumped.at.gshellz.org) has quit (Ping timeout: 264 seconds) | |
| [21:02:24] | sphery: | no, it would be to the benefit of users--who rely on "soft padding" (that doesn't exist) and complain when they don't get it |
| [21:02:46] | sphery: | because then they would learn to do things properly with per-rule start early/end late |
| [21:02:53] | sphery: | (and find "wow, I don't get a lot of conflicts this way") |
| [21:03:01] | stuartm: | ah, ok, you mean "to the benefit of devs who are tired of answering the same question on the mailing list" |
| [21:03:19] | sphery: | because of a) multirec, b) applying padding only when useful (on channels that /are/ often late or whatever, or on shows that /are/ actually important) |
| [21:03:31] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has joined #mythtv | |
| [21:03:35] | stuartm: | if there's a problem it's only that the settings can't be clearly labelled enough |
| [21:04:03] | sphery: | no, I mean that making users think we have a feature we don't and causing them to miss parts of recordings because they didn't set up rules properly and let tuners sit idle rather than using them for overrecord isn't a good thing |
| [21:05:20] | sphery: | anyway, I'll admit that you're doing the work here, so you have far more say than I do |
| [21:05:25] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 245 seconds) | |
| [21:06:15] | sphery: | but I think we'll always have users who complain that they missed something because "I didn't get my soft padding" |
| [21:08:02] | warped_ (warped_!~piotro@89-79-250-31.dynamic.chello.pl) has quit (Client Quit) | |
| [21:09:38] | sphery: | and just enabling the not-guaranteed-by-the-scheduler overrecord when 2 back-to-back shows are recorded from the same multiplex /iff/ using the same physical tuner /iff/ another virtual tuner is available on that card won't get that many more extra cases compared to the amount of work required to get the patch to work without causing problems for more-complex scheduling situations |
| [21:11:22] | sphery: | however, because the scheduler plans for it (and can, therefore, record shows from appropriately-chosen inputs to take advantage of multirec), per-rule start early/end late values would actually probably pick up far more cases |
| [21:13:51] | dekarl: | can you (the plural you) not invest all the time and energy into multirec/hard padding for all sources, even analog ones if its on the same channel? So we would get away with less virtual tuners and get a nice feature for analog capturers, firewire, iptv, etc recorders. |
| [21:14:54] | dekarl: | that would reduce the number of conflicts for everyone :) |
| [21:20:25] | NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [21:24:31] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [21:36:48] | SteveGoodey (SteveGoodey!~SteveGood@host109-158-212-221.range109-158.btcentralplus.com) has quit (Quit: SteveGoodey) | |
| [21:43:22] | skd5aner: | stuartm: no really discernible improvement after applying that patch the other day |
| [21:43:28] | skd5aner: | stuartm: just wanted to let you kno |
| [21:51:29] | stuartm: | skd5aner: ah, shame |
| [21:51:54] | skd5aner: | stuartm: yea, I'm anxious for any magic bullet – it was worth a shot :) |
| [21:52:55] | stuartm: | I wasn't hopeful since the description didn't really match up with my understanding of your problem, but it was worth a shot |
| [21:54:18] | wagnerrp_ (wagnerrp_!4084ae8b@gateway/web/freenode/ip.64.132.174.139) has quit (Quit: Page closed) | |
| [21:54:57] | stuartm: | dekarl: arguably that or some variation – say building 'soft padding' into the scheduler – would please everyone |
| [21:55:20] | stuartm: | until then, let's not throw out the baby with the bathwater |
| [21:57:32] | stuartm: | for dvb I ultimately would like to get running flag support implemented, at the very least for overruns – figuring out how to involve the scheduler in that will be interesting given scheduler runs can take seconds |
| [22:02:12] | Jordack (Jordack!~Jordack@h69-131-44-221.plmomi.dedicated.static.tds.net) has quit () | |
| [22:04:54] | dekarl: | stuartm: something like #10101? |
| [22:05:10] | skd5aner: | also, reading the backlog... I love my soft padding too... please don't change the behavior. I like the fact that my recordigns will typically start 30 seconds ealry and end 90 seconds late. This has saved me multiple times. |
| [22:05:36] | stuartm: | #10101 |
| [22:05:36] | ** MythLogBot http://code.mythtv.org/trac/ticket/10101 ** | |
| [22:05:39] | skd5aner: | I do not want to attempt to manage that on a per-rule basis |
| [22:06:09] | skd5aner: | and, I certainly don't want to hard-pad, because if I have back-to-back recordings I don't need the hard pad to cause a tuner conflict |
| [22:06:25] | dekarl: | hmm, that ticket should be "patch – feature" instead |
| [22:06:33] | stuartm: | dekarl: yeah, exactly like that |
| [22:06:52] | stuartm: | how did I not know, or forget about that patch? |
| [22:07:20] | stuartm: | I'm stealing that from stuarta |
| [22:07:38] | stuartm: | unless he thinks he'll have time for it in the next few weeks |
| [22:09:42] | stuartm: | as he notes, the patch doesn't include the necessary scheduler interaction |
| [22:10:18] | stuartm: | so whoever applies the patch also has to add the scheduler support |
| [22:10:46] | dekarl: | Is there a reason, besides ENODEVTIME, that cppcheck still lists heaps of "Function parameter ' spaceinfront' should be passed by reference."? I'm just mechanically applying them, will add API bump, test compile and commit. But If there are dragons lurking I'd rather know them before :D |
| [22:11:38] | stuartm: | dekarl: dev time and maybe a little bit of not wanting to step on toes |
| [22:12:32] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_) | |
| [22:17:12] | dblain (dblain!~dblain@mythtv/developer/dblain) has quit (Ping timeout: 252 seconds) | |
| [22:18:10] | dekarl: | stuartm: Ahh, according to Wikipedia its called "Accurate Recording" and the BBC has something to do with it... Now that I have the right words to google I can find http://wiki.hummy.tv/wiki/Padding_versus_Accurate_Recording |
| [22:18:26] | dekarl: | (or just follow the link from wikipedia) |
| [22:19:17] | dekarl: | looks like a per channel setting (use accurate recording) might be nice to have |
| [22:20:27] | stuartm: | there's actually nothing stopping us from using a combination of both padding and the 'running' flag |
| [22:21:26] | stuartm: | surprised that a commercial STB is incapable of doing both |
| [22:21:31] | jKlaus_work (jKlaus_work!~jklaus@2600:1004:b01e:5ce6:b858:b0ba:ed79:7df5) has quit (Quit: Leaving) | |
| [22:22:17] | skd5aner: | I have only one recording where I set a hard start early by 2 minutes because it constantly starts earlier than scheduled... but that's because it's so dependably early, that I know I want to do that every time... |
| [22:23:30] | dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv | |
| [22:24:31] | stuartm: | yeah, if you know for certain that the programme is going to run early/late on occassion then you should use hard padding – the only problem seems to be that people aren't aware of the differences and the limitations |
| [22:26:44] | stuartm: | isn't there now an 'avoid back to back recordings' setting anyway? So if you want soft padding on back to back recordings, you'd just use that option? |
| [22:29:36] | jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv | |
| [22:30:20] | skd5aner: | I believe so. yes |
| [22:31:51] | stuartm: | don't want to re-ignite the 'heated debate', better things to be discussing and doing |
| [22:33:15] | Lomion0815: | The 'avoid back to back recordings' setting is on the priority settings page |
| [22:33:39] | stuartm: | wagnerrp: since Paul is now working on completing storage group support for mythmusic, do you think we'd be able to drop local directory support for videos before the next release? It would be nice to draw a line through "Transition everything to storage groups" :) |
| [22:34:09] | Lomion0815 (Lomion0815!~chatzilla@188-23-194-100.adsl.highway.telekom.at) has quit (Quit: ChatZilla 0.9.90.1 [Firefox 26.0/20131205075310]) | |
| [22:34:51] | stuartm: | wagnerrp: I know you've mentioned making some scanning related changes at the same time |
| [22:44:22] | wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has quit (Read error: Connection reset by peer) | |
| [22:44:27] | wahrhaft_ (wahrhaft_!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has joined #mythtv | |
| [22:50:49] | dekarl: | stuartm: I think drawing that line also needs removal of mythtv-setup or moving the channel icon scan to the backend. Its hard to push icons into a SG when the backend is not running ;) |
| [23:02:49] | gigem: | jKlaus: I finally have a few minutes, and I really mean just a few, to jump into today's discusssions. FWIW, pre/post-roll will go away someday or I will die trying. In their place will be some reasonable, automatic conflict resolution. sphery, until that time comes, I'm sorely tempted to just start ignoring user issues which misuse pre/post-roll. skd5aner, I really can't understand statements like "This |
| [23:02:51] | gigem: | has saved me multiple times." How many times have you not been saved then when post-roll wasn't applied? stuartm, I did take a very brief look at #12023 this morning. It looks like there is code that tries to hanlde it properly, so hopefully the fix should be easy. |
| [23:02:51] | ** MythLogBot http://code.mythtv.org/trac/ticket/12023 ** | |
| [23:03:08] | gigem: | jKlaus: It looks like sphery and stuartm covered all of the issues I would have raised about the database. What I will add is that the schema hasn't been "designed" in a long time, if ever. Rather, it has "evolved" over time along with the feature creep. Also, the current program table with chanid/starttime indexes is used throughout MythTV and trying to untangle it will be a long and very disruptive task. |
| [23:03:10] | gigem: | I'm not saying it shouldn't ever be done, but I think you'd be better served by tackling something smaller and simpler first. |
| [23:04:26] | skd5aner: | gigem: Unknown, but I'm grateful for not missing the first 5 seconds of a show, or the last 30 seconds of a show because the broadcaster doesn't care about accurate broadcast times |
| [23:05:44] | skd5aner: | I used the feature for so long, I don't even know at this point how many times it has (or has not) be beneficial, but it certainly has never been detremental over that time period |
| [23:09:40] | gigem: | skd5aner: Users like you with 5s pre and 30s post are not the problem. It's when those times get closer to a minute, and especially when they get much greater, that it becomes silly. |
| [23:10:34] | skd5aner: | FYI , Ithink I do 30 seconds on pre-roll and maybe 90-seconds on post-roll. |
| [23:12:03] | gigem: | Silly! :) |
| [23:19:51] | dekarl: | jya I'd like to push this small patch http://pastebin.com/0Cn6WK9C is that ok with you? |
| [23:30:25] | Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer) | |
| [23:36:27] | jya_: | dekarl: if you have time to waste on this... sure |
| [23:37:36] | dekarl: | :) |
| [23:37:48] | jya_: | dekarl: you do know that the way qt objet are designed, passing them as reference or value has close to no difference? and IRC, the myth coding standard clearly state to pass wt object by value instead of reference |
| [23:37:56] | jya_: | s/wt/qt |
| [23:39:39] | jya_: | something to do with safe-threading |
| [23:39:43] | dekarl: | I'm not aware of that. If that is so, then it would be good to a) adjust the cppcheck configuration to match our / QT style and b) fix all the inconsistencies into the other direction. (some functions get half const values and const references to QStrings) |
| [23:40:38] | jya_: | I would prefer to see time spent on new features, rather than trivial coding standard.. but that's just me |
| [23:45:12] | stuartm: | dekarl: icons are in a storage group local to mythtv-setup, don't need the backend |
| [23:45:23] | stuartm: | we're already storing the icons in a storage group |
| [23:46:09] | dekarl: | stuartm: hmm, that might actually work. IIRC that only leaves collisions in the filename and storing a relative path to do |
| [23:48:03] | stuartm: | jya_: if the objects are const, passing them by reference is both recommended and thread safe, it's only when they are not const that it's not thread safe |
| [23:48:30] | stuartm: | you'll find that 99% of QStrings in the code are passed as a const reference |
| [23:48:42] | dekarl: | jya: hmm, there are points towards just using the COW features and others towards still passing references around.. e.g. http://wiki.hummy.tv/wiki/Padding_versus_Accurate_Recording |
| [23:49:36] | dekarl: | meh, bad paste day: http://developer.nokia.com/Community/Wiki/Rig . . . g_to_methods |
| [23:49:41] | stuartm: | dekarl: collisions in the filename might be a problem for xmltv, it's not an issue for the icon downloader (which already inserts a relative path) |
| [23:50:24] | dekarl: | stuartm I forgot which source it was, but basically every icon was called icon.gif in a different directory |
| [23:51:27] | stuartm: | jya_, dekarl: same applies to other qt class objects, there's a KDE code checker called krazy (iirc) which will warn about all the inefficient QT usage including passing by value instead of a const reference |
| [23:52:14] | stuartm: | dekarl: well that's easy enough, just store the path including the directory? |
| [23:52:41] | dekarl: | stuartm: might get ugly, I was thinking about using some kind of hash. But its down on the list |
| [23:56:02] | stuartm: | dekarl: I thought I'd already modified mythfilldatabase to store the relative path |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.