MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (82):

aberrios, blafoo, Captain_Murdoch, cesman, Chutt, clever, fetzerch, ghoti, Gibby, gigem, joki, kc, kwmonroe, MythLogBot, nameless`, poptix, skd5aner, sl1ce, sraue, superm1, tgm4883, tris, unforgiven512, zentec, _nyloc_, aloril, Anssi, buu, caelor, coling, Cougar, dblain, ElmerFudd, foobum, gregL, GreyFoxx, J-e-f-f-A, jarle, jarryd, jheizer, jnylen, johanbr, jpharvey__, jst, jwhite, kurre2, laga, monkeypet69, MythBuild, neufeld`, Nothing4You, robink, Seeker`, seld_, Sharky112065, stuarta, tonsofpcs, wagnerrp, wahrhaft, whoDat, wseltzer, XDS2010_, xris, dekarl, pitz, peper03, Merlin83b, brfransen, Beirdo, amessina, _charly_, purserj, sphery, TheCras5, nephyrin, wylie, rsiebert_, jams_, natanojl, isaaclw, mrand, moparisthebest_
Sunday, January 12th, 2014, 00:00 UTC
[00:00:09] wagnerrp_ is now known as wagnerrp
[00:00:22] MartinT (MartinT!~smuxi@46-18-104-220.static.vivaciti.org) has quit (Remote host closed the connection)
[00:00:35] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 272 seconds)
[00:16:48] unforgiven512 (unforgiven512!~unforgive@cpe-24-93-204-130.neo.res.rr.com) has quit (Ping timeout: 245 seconds)
[00:19:21] unforgiven512 (unforgiven512!~unforgive@cpe-24-93-204-130.neo.res.rr.com) has joined #mythtv
[01:04:03] dekarl: MartinT, in case you read the logs. QT doesn't support using a bind variable multiple times IIRC.
[01:15:42] arescorpio (arescorpio!~arescorpi@53-243-16-190.fibertel.com.ar) has joined #mythtv
[01:37:09] arescorpio (arescorpio!~arescorpi@53-243-16-190.fibertel.com.ar) has quit (Ping timeout: 248 seconds)
[02:01:15] XDS2010_ (XDS2010_!sid1218@gateway/web/irccloud.com/x-bjdoqijdupiyjqya) has quit (Ping timeout: 245 seconds)
[02:02:55] Chutt (Chutt!~ijr@2605:a000:1208:c08c:551d:f09a:80c8:9e6d) has joined #mythtv
[02:11:25] XDS2010_ (XDS2010_!sid1218@gateway/web/irccloud.com/x-mdgnqmsnfgoipcgr) has joined #mythtv
[02:50:27] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Read error: Connection reset by peer)
[02:56:20] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[03:14:58] _nyloc_ (_nyloc_!~quassel@p3EE2D43C.dip0.t-ipconnect.de) has joined #mythtv
[03:19:01] nyloc (nyloc!~quassel@p57B4FB62.dip0.t-ipconnect.de) has quit (Ping timeout: 248 seconds)
[03:20:44] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Read error: Operation timed out)
[03:25:46] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[03:31:26] TheCrasher (TheCrasher!~TheCrashe@p50807E1E.dip0.t-ipconnect.de) has quit (Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
[03:37:18] moparisthebest (moparisthebest!~quassel@mailer.moparscape.org) has quit (Remote host closed the connection)
[03:37:18] rsiebert_ (rsiebert_!~quassel@f052135245.adsl.alicedsl.de) has joined #mythtv
[03:37:27] rsiebert (rsiebert!~quassel@g225063239.adsl.alicedsl.de) has quit (Read error: Operation timed out)
[03:54:44] moparisthebest (moparisthebest!~quassel@mailer.moparscape.org) has joined #mythtv
[04:40:38] jKlaus (jKlaus!~jesse@adsl-74-242-210-54.rmo.bellsouth.net) has joined #mythtv
[04:40:45] jKlaus: Hey guys
[04:41:26] jKlaus: I'm going to attempt to re-write mythweb implementing IndexedDB if anyone is interested
[04:50:47] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 252 seconds)
[04:52:14] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[05:13:26] XDS2010_ (XDS2010_!sid1218@gateway/web/irccloud.com/x-mdgnqmsnfgoipcgr) has quit ()
[05:37:37] XDS2010_ (XDS2010_!sid1218@gateway/web/irccloud.com/x-sepbdqcpxxjtsjqu) has joined #mythtv
[05:57:26] wagnerrp: as an alternative to sessions stored on the server's database?
[06:11:42] joki (joki!~joki@p54860197.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds)
[06:14:41] jKlaus: wagnerrp, my thought is that I could store the bulk of the information in client DB and only have to update small chunks
[06:14:56] jKlaus: would make the site more responsive
[06:15:37] jKlaus: obviously the first time accessed, or the first time accessed in a long while it would still have to execute a "full" async sync but meh
[06:16:14] jKlaus: any changes made to would be written live back to myth but I figure having local data would be good for something like the record schedule
[06:16:49] jKlaus: That and I just want a project to try IndexedDB on lol
[06:17:06] joki (joki!~joki@p54862A6F.dip0.t-ipconnect.de) has joined #mythtv
[06:20:19] wagnerrp: why not just have it store as a temporary variable in javascript?
[06:20:40] wagnerrp: update the data, but not the page, when moving around in listings
[06:23:33] jKlaus: IndexedDB stores beyond just the current session
[06:23:56] jKlaus: I typically access mythweb once a day at least
[06:24:37] jKlaus: so I could pull the entire tv schedule down and store it in IndexedDB then only have to update one days worth of schedules
[06:24:45] jKlaus: and it could be done asyn
[06:25:33] jKlaus: for instance on 1/1/14 I access it and it stores recordings for 1/1/2014 – 1/14/2014
[06:26:22] jKlaus: I then access it again on 1/2/2014.. it just pulls that information out of the client DB and while its rendering that it can add the 1/15/2014 recordings
[07:27:28] PatrickDickey (PatrickDickey!~quassel@2001:470:1f11:830:e83d:a369:5b83:d16f) has joined #mythtv
[08:09:20] joki (joki!~joki@p54862A6F.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds)
[08:12:08] joki (joki!~joki@p54862CF6.dip0.t-ipconnect.de) has joined #mythtv
[08:14:13] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (Ping timeout: 272 seconds)
[08:45:53] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has joined #mythtv
[09:10:45] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has joined #mythtv
[09:29:29] jKlaus (jKlaus!~jesse@adsl-74-242-210-54.rmo.bellsouth.net) has quit (Quit: Leaving)
[09:43:52] PatrickDickey (PatrickDickey!~quassel@2001:470:1f11:830:e83d:a369:5b83:d16f) has quit (Remote host closed the connection)
[10:17:29] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[10:38:44] paul-h (paul-h!~Paul@176.253.164.179) has joined #mythtv
[10:40:23] stuartm: skd5aner: you might try the patch in #11306
[10:40:23] ** MythLogBot http://code.mythtv.org/trac/ticket/11306 **
[11:08:06] kenni (kenni!~kenni@mythtv/developer/kenni) has quit (*.net *.split)
[11:08:06] knightr (knightr!~Nicolas@mythtv/developer/knightr) has quit (*.net *.split)
[11:08:06] unforgiven512 (unforgiven512!~unforgive@cpe-24-93-204-130.neo.res.rr.com) has quit (*.net *.split)
[11:08:07] sphery (sphery!~mdean@mythtv/developer/sphery) has quit (*.net *.split)
[11:08:07] kc (kc!~Casper@unaffiliated/kc) has quit (*.net *.split)
[11:08:07] poptix (poptix!poptix@poptix.net) has quit (*.net *.split)
[11:08:07] buu (buu!~buu@75.108.226.47) has quit (*.net *.split)
[11:08:07] johanbr (johanbr!~johanbr@vps.nullinfinity.org) has quit (*.net *.split)
[11:08:08] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has quit (*.net *.split)
[11:08:08] Chutt (Chutt!~ijr@2605:a000:1208:c08c:551d:f09a:80c8:9e6d) has quit (*.net *.split)
[11:08:08] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (*.net *.split)
[11:08:08] robink (robink!~quassel@unaffilated/robink) has quit (*.net *.split)
[11:08:09] superm1 (superm1!uid4318@ubuntu/member/superm1) has quit (*.net *.split)
[11:08:09] neufeld` (neufeld`!~user@69-165-173-139.dsl.teksavvy.com) has quit (*.net *.split)
[11:08:10] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has quit (*.net *.split)
[11:14:36] kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv
[11:47:46] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has joined #mythtv
[11:47:46] Chutt (Chutt!~ijr@2605:a000:1208:c08c:551d:f09a:80c8:9e6d) has joined #mythtv
[11:47:46] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[11:47:46] robink (robink!~quassel@unaffilated/robink) has joined #mythtv
[11:47:46] superm1 (superm1!uid4318@ubuntu/member/superm1) has joined #mythtv
[11:47:46] neufeld` (neufeld`!~user@69-165-173-139.dsl.teksavvy.com) has joined #mythtv
[11:47:46] jwhite (jwhite!~jwhite@75-146-153-89-minnesota.hfc.comcastbusiness.net) has joined #mythtv
[11:51:11] knightr (knightr!~Nicolas@mythtv/developer/knightr) has joined #mythtv
[11:51:12] unforgiven512 (unforgiven512!~unforgive@cpe-24-93-204-130.neo.res.rr.com) has joined #mythtv
[11:51:12] sphery (sphery!~mdean@mythtv/developer/sphery) has joined #mythtv
[11:51:12] kc (kc!~Casper@unaffiliated/kc) has joined #mythtv
[11:51:12] poptix (poptix!poptix@poptix.net) has joined #mythtv
[11:51:12] buu (buu!~buu@75.108.226.47) has joined #mythtv
[11:51:12] johanbr (johanbr!~johanbr@vps.nullinfinity.org) has joined #mythtv
[12:02:50] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[12:15:07] wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has quit (Ping timeout: 245 seconds)
[12:18:30] wahrhaft (wahrhaft!~quassel@cpe-24-210-69-143.columbus.res.rr.com) has joined #mythtv
[13:37:30] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has quit (Ping timeout: 245 seconds)
[13:49:55] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has joined #mythtv
[13:53:00] dekarl (dekarl!~dekarl@p4FE845DC.dip0.t-ipconnect.de) has quit (Read error: Operation timed out)
[13:53:06] dekarl1 (dekarl1!~dekarl@p4FE8429E.dip0.t-ipconnect.de) has joined #mythtv
[13:57:09] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has joined #mythtv
[13:57:09] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[13:57:09] stichnot (stichnot!~stichnot@adsl-68-127-209-56.dsl.pltn13.pacbell.net) has quit (Changing host)
[13:57:28] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer)
[13:58:14] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has joined #mythtv
[13:59:45] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has quit (Read error: Connection reset by peer)
[14:00:24] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has joined #mythtv
[14:05:59] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has quit (Max SendQ exceeded)
[14:06:43] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has joined #mythtv
[14:32:03] jpharvey__ (jpharvey__!~jpharvey@host109-148-239-207.range109-148.btcentralplus.com) has quit (Ping timeout: 272 seconds)
[14:33:04] TheCrasher (TheCrasher!~TheCrashe@p50807E1E.dip0.t-ipconnect.de) has joined #mythtv
[14:43:30] jpharvey__ (jpharvey__!~jpharvey@host109-156-7-208.range109-156.btcentralplus.com) has joined #mythtv
[14:57:24] skd5aner: stuartm: thanks, compiling now
[15:11:27] doev (doev!~doev@p4FD43130.dip0.t-ipconnect.de) has quit (Ping timeout: 260 seconds)
[15:12:16] stichnot: sphery: #12004 – I feel the user's "intolerable" pain, and I think that this deserves to be put back into a setting (though not a binary setting like it started out). The code is already structured to use a floating point value between 0 and 1 to specify the accuracy level, making it easy to present a 0%-100% slider. It could be made a live setting in the Playback OSD menu so it's easier...
[15:12:16] ** MythLogBot http://code.mythtv.org/trac/ticket/12004 **
[15:12:17] stichnot: ...to discover and fine-tune, though that location doesn't really allow the extended help text that the Setup page has. Even cooler if the keybindings could work out such that the user could test the live setting without having to dismiss the dialog. Thoughts?
[15:13:53] skd5aner: stichnot: +3
[15:14:41] skd5aner: stichnot: and by that, I mean... the "intolerable pain" part
[15:17:57] skd5aner: seeking backwards in HDPVR recordings is.... teeth grittingly slow to repsond
[15:21:43] stichnot: skd5aner: for me it's most painful during editing HDPVR recordings, but that's trickier because for frame-accurate editing you typically want a higher level of accuracy.
[15:21:44] MartinT (MartinT!~smuxi@46-18-104-220.static.vivaciti.org) has joined #mythtv
[15:22:36] skd5aner: yea, but I stopped editing HDPVR recordings because of the fact I can't really losslessly transcode them and even if I tried the keyframes are so far apart that it makes it kinda ugly
[15:23:05] skd5aner: you're right htough – editing an HDPVR recording is an excercise in patience
[15:24:02] stuartm: stichnot: better to tweak the logic so that it works well – for every one user who finds and understands the setting there will be 20 who don't
[15:25:22] MartinT: dekarl1: just looked up the multiple bind issue and you recall correctly... seems like a bit of a limitation to me...
[15:26:05] stuartm: stichnot: if a percentage is too inaccurate, then include a flat min value instead
[15:28:12] stichnot: stuartm: I think the logic is pretty solid as it stands, but it can never 100% satisfy the power users
[15:28:56] skd5aner: stuartm: patch applied succesfully, up and running now – I'll report back later in the week if there's any positive (or negative) feedback – thanks for the heads up!
[15:29:17] stichnot: And percentage is almost certainly the right way to go. e.g. if I seek by 30 seconds or 10 minutes, my tolerance for inaccurate seeks is much higher than if I seek 5 seconds
[15:29:27] stuartm: the ticket submitter had some suggestions, I'm sure a compromise can be found – take the 'bookmark' logic for example, there we use a percentage but with minimum and maximum hard limits
[15:29:53] stichnot: stuartm: what bookmark logic?
[15:29:55] skd5aner: stichnot: I would argue the seeking is almost essentially "broken" as-is. It works, but man it's extremely kludgy. It definitely gets an "D-" from a UX perspective
[15:30:04] stuartm: stichnot: sorry, meant the 'watched' logiv
[15:30:09] stuartm: logic
[15:30:12] skd5aner: sorry... to clarify, just for HDPVR recordings
[15:32:01] stuartm: e.g. if we're within 10% of the program endtime or 5 minutes, whichever is longer, then we mark something as watched
[15:32:34] stichnot: skd5aner: can you clarify? For my 720p HDPVR recordings, seeking 30s forward and 8s backward gives pretty reasonable responsiveness and perceived accuracy on my ION frontends. Where do you see problems?
[15:34:09] skd5aner: stichnot: sure... as we speak, I'm watching a 1080i recording, when I try to skip back 5 seconds, the video pauses for about 1 second and then finally jumps
[15:35:20] skd5aner: If I push the the back button 5 times in a row, and semi-rapid fashion, the video puases for about 3–5 seconds, and then eventually jumps and plays
[15:36:07] skd5aner: jumping forward by 30 seconds is pretty responsive though
[15:36:13] stichnot: skd5aner: For 1080i HDPVR recordings, what is the time between keyframes? For 720p, I know it puts keyframes every 128 frames, meaning just over 2 seconds between keyframes
[15:36:36] skd5aner: well, let me check...
[15:36:48] stichnot: (you can probably check easily in the cutlist editor)
[15:37:31] skd5aner: 128
[15:37:53] stichnot: ok, but what does that translate to in seconds?
[15:38:42] stichnot: cutlist editor, set seek distance to "keyframe", and watch the timecode as you advance by 1 keyframe
[15:39:02] skd5aner: 4.271 secs
[15:39:23] skd5aner: yes, I know, that's what I was doing... just took me a few seconds ;)
[15:39:33] stichnot: hmm, yuck
[15:41:23] stichnot: so if you want to skip back 5 seconds, are you ok if it actually skips back anywhere between 1–9 seconds, say?
[15:41:45] skd5aner: 1–9, probably not...
[15:41:50] skd5aner: 5–9, maybe
[15:42:22] stichnot: do I hear 3–7?
[15:42:42] skd5aner: meet you in the middle at 5, and you've got a deal!
[15:42:44] skd5aner: ;)
[15:42:46] stichnot: :)
[15:43:38] skd5aner: I definitely don't care for "Frame" accuracy in anything except for frame-by-frame seeking in pause or the editor
[15:45:03] stuartm: actually, I think most people would be content with it jumping back more than requested but not less
[15:45:04] stichnot: stuartm: there is already something of a min/max limit built in, which is the keyframe distance (can be variable, but usually bounded)
[15:46:00] stuartm: if you skip back it's because you missed something – whether it's the start of the program after a commercial or a key bit of dialogue was missed
[15:46:40] stichnot: skd5aner: I think seeking to a bookmark imposes 100% accuracy, as does setting seek distance to 1 frame in the cutlist editor, but everything else allows the % inaccuracy
[15:47:07] stuartm: skipping '5 seconds' but only achieving 1–4 doesn't help in any case, jumping 5–10 can't actually hurt
[15:48:53] stichnot: if normal playback is paused (e.g. in the editor), skipping back 1–4s instead of 5s is probably tolerable
[15:49:27] stuartm: yeah, in this instance I'm refering solely to the Skip/Jump actions, not the editor etc
[15:50:56] stichnot: right, the point being to avoid racing between forward playback and the person trying to skip backwards while making decisions
[15:52:15] stuartm: if we _always_ target the keyframe previous to our seek point that resolves the whole speed issue
[15:52:28] stuartm: for normal playback
[15:52:38] MartinT: stuartm: just sent another pull, this one has a trac issue... not sure how to raise it properly, so let me know if there is anything else I need to do... #12012
[15:52:38] ** MythLogBot http://code.mythtv.org/trac/ticket/12012 **
[15:54:25] MartinT: I was going to do it in regex, but with no look behinds, I was struggling...
[15:55:14] MartinT: it could go into 0.27 as a fix, but the unit tests aren't in there, and I'm not overly bothered... it was busy work...
[15:58:45] stichnot: stuartm, skd5aner: maybe what we really want is a wall clock time budget on exact seeks, and give the best effort within that budget
[16:00:59] stichnot: Seeking works by making a fast seek to the nearest preceding keyframe, then decoding forward one frame at a time until the desired frame is found. If we instead decode forward one frame at a time until the desired frame is found -OR- we run out of time, that could be a good user experience
[16:02:21] stuartm: stichnot: that could work, more complicated than simply always going for the keyframe but if you're willing to put in the effort
[16:02:24] stichnot: and when we run out of time, we wouldn't resume playback at a keyframe, but rather a few frames later where we ran out of time
[16:02:45] stichnot: stuartm: it's already more complicated than just going for the keyframe :)
[16:10:48] skd5aner: stichnot: If all HDPVR recordings have keyframes at 128frames, and we know the average time between keyframes for 720p material is x and for 1080i material is y and 480i is z, then couldn't you know approximately which frame to skip to in order to jum a specified amount of time?
[16:10:54] skd5aner: or am I oversimplifying it?
[16:12:11] skd5aner: So, if I want to jump back 5 seconds in a 1080i HDPVR recording, just jump back ~140 frames (or whatever it'd be). Instead of decoding frames from the keyframe
[16:13:00] stichnot: You need to start from a keyframe and iterate forward, otherwise you end up with nasty pixelation
[16:13:14] skd5aner: ok
[16:13:21] stichnot: and that's an F- on UX :)
[16:13:27] skd5aner: yup
[16:21:09] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has quit (Quit: Leaving)
[16:21:32] stichnot: skd5aner: any chance you could give me a ~5-minute 1080i 29.97fps HDPVR recording? (I am loath to touch my production recording setup :) )
[16:21:56] skd5aner: sure, just want me to truncate it with DD?
[16:22:13] stichnot: yeah, that should work
[16:22:25] skd5aner: any preferences? Seasame Street work? :)
[16:22:41] stichnot: Sesame Street is OK, just not Teletubbies please :)
[16:32:16] skd5aner: stichnot: how do you want me to get it to you... 50MB got me 36 secs of video, so it'll be at least 450MB
[16:32:58] skd5aner: 416MB I suppose it would be
[16:34:48] stichnot: skd5aner: if you're on gmail, my method of choice is to upload to Google Docs/Drive and share it from there
[16:34:57] skd5aner: k
[16:35:19] skd5aner: got the file ready, but I've got step away fro a bit, I'll get it ready for you when I return
[16:35:35] stichnot: ok thanks
[17:23:43] TheCras5 (TheCras5!~TheCrashe@p5DCE4DF7.dip0.t-ipconnect.de) has joined #mythtv
[17:27:02] TheCrasher (TheCrasher!~TheCrashe@p50807E1E.dip0.t-ipconnect.de) has quit (Ping timeout: 252 seconds)
[17:53:53] stichnot: skd5aner, stuartm, anyone: try this patch for faster seeking – http://pastebin.com/zpQJGPb3
[17:54:53] stichnot: It cuts off the frame-by-frame seeking after 100ms. This is extreme in that 100ms may be too low and it's done for all seeks, but a reasonable proof of concept.
[18:06:23] MartinT (MartinT!~smuxi@46-18-104-220.static.vivaciti.org) has quit (Ping timeout: 272 seconds)
[18:18:16] andrewsw (andrewsw!~andrew@swclan.homelinux.org) has joined #mythtv
[18:23:35] dekarl1 is now known as dekarl
[18:28:21] kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Ping timeout: 248 seconds)
[18:28:24] andrewsw (andrewsw!~andrew@swclan.homelinux.org) has left #mythtv ()
[18:40:28] kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv
[18:54:08] cotterpin (cotterpin!~hp-mini@202-180-127-120.callplus.net.nz) has joined #mythtv
[18:55:18] MartinT (MartinT!~smuxi@46-18-104-220.static.vivaciti.org) has joined #mythtv
[18:56:22] cotterpin: the default hdpvr HD setup uses keyframe intervals 128 but with seekable I frames every 32
[18:57:28] cotterpin: mythtv was (is) identifying seekable I frames as keyframes (bad for cutting)
[18:59:27] cotterpin: A better soln could be to identify seekable I -frames & store that info in DB tables (as a new type). The decoder can start playable from seekable I-frame if it has the correct previous SPS/PPS.
[19:04:22] cotterpin: Just using all I-frames as key results in frame offset errors in cutting/editing tools. And just using real keyframes (for hdpvr) results in huge keyframe distances. Pity the linux hdpvr driver never supported all the h264 encoder options.
[19:05:28] gregL (gregL!~greg@cpe-74-76-105-205.nycap.res.rr.com) has joined #mythtv
[19:10:51] skd5aner: stichnot: do you have a dropbox account?
[19:11:04] skd5aner: stichnot: if so, I could add you to a shared folder I have
[19:19:31] stichnot: skd5aner: no I don't, but I could create one if they aren't too scummy/scammy/spammy
[19:20:11] stichnot: actually, never mind, I was able to recreate a bad user experience with 720p for testing
[19:20:17] skd5aner: I get 0 emails from them, and they're pretty much the biggest player
[19:20:44] skd5aner: yea, but would still be good to have a 1080i clip I would assume to test under the same conditions
[19:20:46] stichnot: I think it was bad all along, and I had just learned to ignore it
[19:20:53] stichnot: true
[19:21:03] skd5aner: I could put it on google drive too I suppose
[19:21:06] skd5aner: I have both
[19:21:19] skd5aner: I just don't have the client installed on this desktop
[19:22:10] stichnot: OK I signed up under my @gmail.com address
[19:22:40] skd5aner: k, if you want a dropbox account, let me know – I'll get more storage for referals – heh :)
[19:23:14] stichnot: oh, too bad, I meant I already signed up for dropbox so it's probably too late for referrals :(
[19:24:57] stichnot: Regarding that idea/patch to put an upper time limit on frame-by-frame seeking. I think that, when added to the current distance-based snapping, this is a really great approach for the user experience, and I wish I had thought of it years ago.
[19:30:33] skd5aner: stichnot: alright, link sent to gdrive, and the file is currently uploading – let me know when you've pulled it down
[19:31:06] stichnot: ok, keeping an eye out
[19:32:02] cotterpin (cotterpin!~hp-mini@202-180-127-120.callplus.net.nz) has left #mythtv ()
[19:51:20] MartinT_ (MartinT_!~smuxi@46-18-104-220.static.vivaciti.org) has joined #mythtv
[19:51:57] MartinT (MartinT!~smuxi@46-18-104-220.static.vivaciti.org) has quit (Ping timeout: 252 seconds)
[20:05:56] MartinT_ is now known as MartinT
[20:06:07] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has quit (Quit: Leaving)
[20:08:09] skd5aner: stichnot: it's done uploading it looks like
[20:09:12] jarle (jarle!~jarle@70.84-234-133.customer.lyse.net) has joined #mythtv
[20:10:00] stichnot: OK. I have to wait for someone to finish watching their streaming video before I can download. :)
[20:37:24] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 276 seconds)
[20:39:09] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[20:49:45] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[21:37:07] MartinT: got a quick development question, are there any QT/Myth guru's around?
[21:46:58] kenni (kenni!~kenni@mythtv/developer/kenni) has quit (Ping timeout: 246 seconds)
[21:59:19] kenni (kenni!~kenni@port649.ds1-ly.adsl.cybercity.dk) has joined #mythtv
[21:59:19] kenni (kenni!~kenni@mythtv/developer/kenni) has joined #mythtv
[21:59:19] kenni (kenni!~kenni@port649.ds1-ly.adsl.cybercity.dk) has quit (Changing host)
[22:10:49] Steve-Goodey (Steve-Goodey!~steve@host109-158-212-221.range109-158.btcentralplus.com) has quit (Quit: Konversation terminated!)
[22:35:44] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has quit (Read error: Connection reset by peer)
[22:55:32] jheizer (jheizer!~jheizer@c-98-226-220-178.hsd1.il.comcast.net) has joined #mythtv
[22:56:19] MartinT: can someone give me a quick bit of advice... I'm new to cpp (learning alot programming in myth..)
[22:56:34] MartinT: getting this error, that I assume is a basic syntax error...
[22:56:37] MartinT: no known conversion for argument 1 from ‘const metadata_list {aka const std::list<simple_ref_ptr<VideoMetadata> >}’ to ‘VideoMetadataListManager::metadata_list& {aka std::list<simple_ref_ptr<VideoMetadata> >&}’
[22:57:12] MartinT: I'm calling a method like this... m_metadata->setList(list);
[22:58:46] buu: MartinT: I think it wants you to pass a reference to the list
[22:59:05] MartinT: ok, is that a simple syntax change?
[22:59:12] buu: Try: &list
[22:59:40] buu: MartinT: How did you declare list?
[23:00:11] MartinT: comes in as a parameter on the method...
[23:00:12] MartinT: const metadata_list &list
[23:00:30] buu: Oh um.
[23:01:40] buu: MartinT: Do you know where metadata->setList is defined?
[23:01:47] MartinT: yup...
[23:02:04] MartinT: void VideoMetadataListManager::setList(metadata_list &list)
[23:03:23] buu: Huh
[23:05:57] buu: MartinT: Are you sure its supposed to be 'const'?
[23:06:11] MartinT: thinking about it, maybe not...
[23:07:00] buu: None of the other setLists declare it as const
[23:07:56] MartinT: that sorted it... I'll work out why another day...
[23:08:02] buu: Heh
[23:08:12] buu: Because you were passing a const to a non const function!
[23:09:04] MartinT: yeah I get that, but not sure why I declared it as a const... and as I'm normally a c# programmer, declarations like that make no sense...
[23:09:08] buu: MartinT: I'll note that most of the code seems to declare it as 'VideoMetadataListManager::metadata_list' instead of just 'metadata_list', not sure if that makes any difference
[23:09:53] MartinT: depends where it is... this is in the listmanager class, so I don't think it's needed...
[23:10:28] stuartm: c# has no const keyword?
[23:11:20] MartinT: yes, but at the class level, not in method definitions
[23:12:12] Tobbe5178 (Tobbe5178!~asdf@h104n2-sv-a13.ias.bredband.telia.com) has quit (Read error: Connection reset by peer)
[23:12:51] MartinT: stuartm: take it you haven't had chance to look at those pulls? I've sent 2 more... those have trac's though...
[23:13:37] MartinT: buu: that helped me get closer... now to figure out the service api response objects...
[23:16:06] moparisthebest (moparisthebest!~quassel@mailer.moparscape.org) has quit (Remote host closed the connection)
[23:16:21] MartinT: anyway... off to bed, 23:15... rock and roll! stuartm, I'll catch up on the logs if you have any notes...
[23:16:38] MartinT (MartinT!~smuxi@46-18-104-220.static.vivaciti.org) has quit (Remote host closed the connection)
[23:20:36] Guest3936 (Guest3936!~quassel@mailer.moparscape.org) has joined #mythtv
[23:35:04] paul-h (paul-h!~Paul@176.253.164.179) has quit (Quit: Konversation terminated!)
[23:48:18] Guest3936 (Guest3936!~quassel@mailer.moparscape.org) has quit (Read error: Connection reset by peer)
[23:57:21] moparisthebest_ (moparisthebest_!~quassel@mailer.moparscape.org) has joined #mythtv

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