:: #mythtv

Daily chat history

Current users (76):

aca20031, aloril, amessina, Anssi, Beirdo_, bobweaver, brfransen, cesman, Chutt_, clever, coling, Cougar, danielk221, dblain, dekarl, ElmerFudd, ephemer0l, fetzerch, foobum, foxbuntu`, ghoti, Gibby, gregL, GreyFoxx, J-e-f-f-A, jams_, jarle, jarryd, jheizer, joe_____, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, knightr, kormoc, KungFuJesus, kurre2, kwmonroe, laga, MavT, moparisthebest, mrand, MythBuild, MythLogBot, neufeld, Nothing4You, nyloc, poptix, purserj, pvr4me, rhpot1991, rsiebert_, seld, Sharky112065, SmallR2002, sphery, sraue, stuartm, superm1, tgm4883, Tobbe5178, tonsofpcs, tris, unforgiven512, wagnerrp, wahrhaft_, whoDat_, wilmoore-misc, wolfgang2, XDS2010_, xris, _charly_
Sunday, June 16th, 2013, 00:07 UTC
[00:07:07] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[00:50:48] cesman (cesman! has joined #mythtv
[00:50:48] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[00:50:48] cesman (cesman! has quit (Changing host)
[01:08:03] gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.0)
[01:08:32] gigem (gigem! has joined #mythtv
[01:08:32] gigem (gigem! has quit (Changing host)
[01:08:32] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[01:34:34] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[01:35:27] pvr4me (pvr4me! has quit (Quit: pvr4me)
[01:43:41] gary_buhrmaster (gary_buhrmaster!~gtb@2001:470:80e4:3::36) has left #mythtv ()
[01:44:06] gary_buhrmaster (gary_buhrmaster!~gtb@2001:470:80e4:3::36) has joined #mythtv
[01:47:22] map7_ (map7_! has joined #mythtv
[01:47:58] map7_ (map7_! has quit (Client Quit)
[02:02:22] Sharky112065 (Sharky112065! has quit (Ping timeout: 252 seconds)
[02:09:41] _nyloc_ (_nyloc_! has joined #mythtv
[02:10:16] nyloc (nyloc! has quit (Ping timeout: 246 seconds)
[03:12:56] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[03:25:04] jya_: stuartm: I have doubt your commit 516719ad7e750a258bd2f72f79eae099f79d303b that change util-nvctl.cpp is good… you've reduced the definition of the but to 8, when in the code buf[8] is used
[03:28:16] jya_: oh, I see you fixed that in a following commit
[03:29:05] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds)
[03:30:22] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[03:32:26] jya_: BTW: there's no way libnvctrl ever returned an invalid mode line… Those tests to check the mode line are effectively unnecessary. I liked that the log was in playback; as you see them during playback when video framerate is changing...
[03:34:46] jya_: had planned to go into my coverity queue today; seems someone did it for me...
[03:38:25] KungFuJesus (KungFuJesus!~adam@ has quit (Read error: Connection reset by peer)
[03:42:51] KungFuJesus (KungFuJesus!~adam@ has joined #mythtv
[03:57:43] joki (joki! has quit (Ping timeout: 268 seconds)
[04:02:25] joki (joki! has joined #mythtv
[04:33:46] Sharky112065 (Sharky112065! has joined #mythtv
[05:40:29] MavT (MavT! has joined #mythtv
[07:16:43] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Ping timeout: 264 seconds)
[07:18:02] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv
[07:40:09] SteveGoodey (SteveGoodey! has joined #mythtv
[08:28:54] stoffel (stoffel! has joined #mythtv
[08:36:28] stuartm: jya_: actually the logging I threw in showed that it was returning invalid lines, more than one in fact
[08:40:52] stuartm: might be interesting to actually include the modeline in the warning, although it doesn't matter to us
[08:41:13] exoon (exoon! has joined #mythtv
[09:13:25] stuartm: jya_: 'invalid' modelines returned by libnvctrl for me include three instances of – "nvidia-auto-select" 106.500
[09:39:34] stoffel (stoffel! has quit (Ping timeout: 252 seconds)
[09:52:14] _nyloc_ (_nyloc_! has quit (Remote host closed the connection)
[09:54:31] nyloc (nyloc! has joined #mythtv
[09:57:31] peper03 (peper03! has joined #mythtv
[10:57:31] wolfgang2 (wolfgang2! has quit (Read error: Operation timed out)
[11:13:04] wolfgang2 (wolfgang2! has joined #mythtv
[11:44:18] wolfgang2 (wolfgang2! has quit (Ping timeout: 245 seconds)
[11:59:03] wolfgang2 (wolfgang2! has joined #mythtv
[12:21:09] paul-h (paul-h!~Paul@ has joined #mythtv
[12:24:30] knightr (knightr! has joined #mythtv
[12:24:31] knightr (knightr! has quit (Changing host)
[12:24:31] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[12:47:24] exoon (exoon! has quit (Ping timeout: 252 seconds)
[12:52:43] stichnot_ (stichnot_! has joined #mythtv
[12:54:32] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 245 seconds)
[12:54:38] stichnot_ is now known as stichnot
[13:02:38] natanojl (natanojl! has joined #mythtv
[13:11:09] paul-h: Captain_Murdoch: there is a potential problem with the MythDownloadManager methods that take a QNetworkRequest * in that MDM takes ownership of the request and deletes it but the docs don't mention that at all
[13:14:19] paul-h: So if you do something like this you get and abort – QNetworkRequest req(url); GetMythDownloadManager()->post(&req, &data);
[13:21:15] stoffel (stoffel! has joined #mythtv
[13:23:28] paul-h: The ImportIconsWizard screen is painful to use since scrolling in the list seems to cause all the visible icons to re-download :(
[13:42:55] natanojl (natanojl! has quit (Ping timeout: 276 seconds)
[14:17:27] stichnot (stichnot! has quit (Ping timeout: 245 seconds)
[14:32:55] paul-h: dblain: or anyone else who knows the code can you please cast your eye over this patch it removes the last HttpComms stuff but I wouldn't know where to start testing the soap stuff
[14:39:44] paul-h: dblain: a comment in the code says "userAgent, UPnP/1.0 very strict on format if set" MythDownloadManager sets the user agent to something like "MythTV v0.27.20130609–2 MythDownloadManager" is that OK?
[14:42:30] XChatMav (XChatMav! has joined #mythtv
[14:43:49] stichnot (stichnot! has joined #mythtv
[14:43:50] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[14:43:50] stichnot (stichnot! has quit (Changing host)
[14:45:03] MavT (MavT! has quit (Ping timeout: 252 seconds)
[14:51:49] gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.0)
[14:52:23] gigem (gigem! has joined #mythtv
[14:52:23] gigem (gigem! has quit (Changing host)
[14:52:23] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[15:01:55] stoffel (stoffel! has quit (Remote host closed the connection)
[15:31:41] stichnot (stichnot! has joined #mythtv
[15:31:41] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:31:41] stichnot (stichnot! has quit (Changing host)
[15:36:48] gary_buhrmaster (gary_buhrmaster!~gtb@2001:470:80e4:3::36) has left #mythtv ()
[16:11:34] rsiebert_ (rsiebert_! has joined #mythtv
[16:12:22] rsiebert (rsiebert! has quit (Ping timeout: 246 seconds)
[16:30:46] paul-h: danielk221: OK if I remove both mythhttphandler* and mythhttppool* there's nothing left still using it that I can see?
[17:20:31] Nothing4You (Nothing4You! has joined #mythtv
[17:25:56] stichnot (stichnot! has joined #mythtv
[17:25:56] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:25:56] stichnot (stichnot! has quit (Changing host)
[17:38:11] peper03: stuartm: Was just pondering whether to try to fix DVD bookmark handling for 0.27. It would need a DB schema update, which I guess would preclude it from being added to 0.27 once released (i.e. it would have to be pushed back to 0.28). On the other hand, I don't want to bust a gut if it's unlikely to be included in 0.27 anyway for whatever reason.
[17:38:29] peper03: Basically, the data from this structure needs to be stored in the DB: . . . /vm/vm.h#L35
[17:40:37] peper03: I've not started anything yet but I think it should be do-able. Mainly a question of how best to store that data in the DB.
[17:48:50] natanojl (natanojl! has joined #mythtv
[17:59:32] stoffel (stoffel! has joined #mythtv
[18:04:29] natanojl: jya: stuartm:
[18:05:59] stuartm: peper03: I'm not sure if we're intending to stick to the freeze date for 0.27, which is tomorrow, obviously that wouldn't leave you a lot of time, but I'd be happy to include it if it was ready by then (or any revised date)
[18:07:34] stuartm: personally I would have liked one more week before the freeze to get a couple of things in, but we'll see :)
[18:10:59] peper03: stuartm: Ah, hadn't realised the freeze date was already tomorrow :-o That *would* be a bit tight! With any freeze date, people would always like it pushed back "just a bit" as it comes looming :)
[18:11:55] peper03: What's the situation with existing tickets and the freeze date? There are still a few of my tickets open.
[18:12:24] peper03: i.e. Patches
[18:14:47] stoffel (stoffel! has quit (Ping timeout: 260 seconds)
[18:45:01] peper03: Since I have little experience of the pros and cons of database design, does anyone have any suggestions for how the store the DVD state data? The registers alone need 72 values (24 system registers, 16 general registers and for each general register, there's a mode and time value to be stored). Add in the other state values and you're up to 88 values.
[18:47:17] peper03: That feels a bit unwieldy for one record but have you gained much by splitting the registers out into a separate table? Each record in that table would need an additional column to identify the register type and number. Creating a bookmark would then require 72 SQL statements for the registers (unless there's some way to join them into one?)
[18:49:40] gigem: stuartm, peper03: I suspect there wouldn't be much problem with giving freeze exceptions to specific features with expected due dates.
[18:51:31] stuartm: peper03: you don't gain from splitting out into individual tables, in fact the opposite, the more 'joins' the slower it would be
[18:53:06] stuartm: actually, now that I've re-read what you said, you do want to split out the general registers at least, but you wouldn't need 72 sql statements :)
[18:55:19] stuartm: the register table would have the following four columns – bookmarkid, registertype (or name), mode, time
[18:56:25] stuartm: you'd simply SELECT * FROM dvdregisters WHERE bookmarkid='264'; then iterate over the results to populate your vm with the correct values
[18:58:14] peper03: stuartm: That was my thought too. It's certainly easier from an implementation point of view but since there are always a fixed number of registers to be read for each bookmark, I wasn't sure whether that wasn't a case of me trying to make my life easier at the expense of the design.
[18:58:18] hotwings (hotwings! has joined #mythtv
[18:58:31] stuartm: you'd not gain anything in performance or storage, but it's more flexible (new registers can be added without schema changes)
[18:58:47] hotwings: does myth support vdpau via amd uvd?
[18:59:29] stuartm: peper03: it's considered good design to break up data in that way
[19:00:53] dekarl (dekarl! has quit (Ping timeout: 240 seconds)
[19:00:54] peper03: stuartm: Yeah, I remember happy *cough* days at uni iterating over database designs to remove redundancy etc.
[19:01:13] stuartm: e.g. where you have multiple sets of identically structured data associated with one particular record, you always want those in another table rather than stored in dozens of columns
[19:01:36] peper03: How about writing the values. One big INSERT INTO like in the backup scripts?
[19:02:49] stuartm: nah, for the sake of readability I'd use a for loop to step through the registers and INSERT one at a time, if this is at all possible
[19:03:13] stuartm: big SQL statements are a pain to read
[19:04:31] stuartm: seems like it should be from the struct definition
[19:05:04] stuartm: much less code too
[19:05:29] dekarl (dekarl! has joined #mythtv
[19:05:57] peper03: From an implementation point of view that would be much easier. I didn't fancy the idea of having to refer to each and every value individually.
[19:06:52] peper03: But that means 72 SQL statements per write, doesn't it?
[19:07:13] peper03: Not that the bookmarks are being written constantly, though.
[19:07:53] peper03: Sorry, not 72. 16+24, so 40.
[19:11:15] jpabq: I am okay with the freeze date slipping a week. However, I don't think we should let it slip any more than two weeks, or it will become perpetual...
[19:14:43] peper03: Also, I doubt that the old bookmarks can be converted. As the current implementation is a bit hit and miss (depending on the DVD), I assume that's not big deal. I suppose the new fields could be added to the existing table and the code would determine whether an old or new style bookmark was read. That would make the code a bit more complicated but I assume it's do-able.
[19:18:01] hotwings (hotwings! has left #mythtv ()
[19:29:11] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[19:44:20] stuartm: peper03: 72 isn't that many, not compared to things like the seektable or music/video scans which can be inserting hundreds/thousands of records
[19:46:53] stuartm: I think for most people existing dvd bookmarks lose their value after a few days, you'd only tend to use them where you were interrupted or didn't have time to finish watching something, if you return to something after more than a few days you've probably forgotten details from the start of the programme/film and will want to re-watch it
[19:47:35] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[19:48:05] stuartm: so at worst we're just requiring a few people to skip through the video to find their old position on whatever they were most recently watching
[20:35:01] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[20:48:21] wilmoore-misc (wilmoore-misc! has quit (Remote host closed the connection)
[20:58:11] peper03: stuartm: Ok. Looking at what's stored now, it may be possible to use most of those values (title, audio track and subtitle track) depending on whether the values match 1:1 what would be stored anyway in the state structure somewhere, but I'm not sure yet about how important the frame number is to the rest of the code. It's used in several places in mythplayer.cpp but how many of those actually have any effect when playing DVDs, I'm not
[20:58:13] peper03: sure. If worst comes to worst, that has to stay in even though I don't *think* it's necessary in the context of DVD playback.
[21:10:43] stuartm: I don't think maintaining backwards compatibility with old timestamps is important
[21:15:55] peper03: The timestamp value is when the bookmark was created. I thought there was a setting somewhere to delete bookmarks > x days, but I'm not sure. That's less the problem. At the moment, it's mainly the title and frame number that are stored. At the moment, I don't fully understand which of the places the frame number is used actually have any effect in this context.
[21:19:42] peper03: Zero seems to be that no bookmark is set, but the frame number is also used to update the cutlist ( . . . er.cpp#L1000 ), which, as far as I'm aware, isn't available during DVD playback so faking the value probably wouldn't matter there.
[21:20:37] peper03: I'll have to have a play around to get to grips with it :)
[21:24:23] stuartm: peper03: we store the frame number to seek to that position within the title, it's only used for that purpose
[21:25:41] wilmoore-misc (wilmoore-misc! has joined #mythtv
[21:35:22] peper03: stuartm: Yeah, but with the DVD state data in hand, the frame number should be irrelevant. If it were only used in MythDVDPlayer, I could remove it and it wouldn't be a problem but the fact that it's used in MythPlayer means I have to be a bit more careful about understanding where and how it's used, and whether I can get away with faking it to satisfy that bit of code or whether that will come back to bite me :-o
[21:37:13] peper03: I doubt it's going to be a make-or-break issue, just something that needs a closer look.
[21:42:25] XChatMav (XChatMav! has quit (Ping timeout: 256 seconds)
[21:42:48] MaverickTech (MaverickTech! has joined #mythtv
[21:46:30] paul-h (paul-h!~Paul@ has quit (Quit: Konversation terminated!)
[21:46:54] MavT (MavT! has joined #mythtv
[21:48:28] MaverickTech (MaverickTech! has quit (Ping timeout: 276 seconds)
[22:01:12] natanojl (natanojl! has quit (Ping timeout: 268 seconds)
[22:15:53] peper03 (peper03! has quit (Quit: Konversation terminated!)
[22:41:49] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Ping timeout: 256 seconds)
[22:42:14] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[23:39:02] pvr4me (pvr4me! has joined #mythtv
[23:55:12] pvr4me_ (pvr4me_! has joined #mythtv
[23:57:21] pvr4me (pvr4me! has quit (Ping timeout: 256 seconds)
[23:57:22] pvr4me_ is now known as pvr4me

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