:: #mythtv

Daily chat history

Current users (85):

aloril, amessina, Anssi, anykey_, Beirdo, Ben64, brfransen, bsilvereagle, CaCtus491, Captain_Murdoch, cecil, Chutt, clever, coling, Cougar, danielk22, dblain, dekarl, ElmerFudd, f33dMB, fetzerch, foobum, foxbuntu, ghoti, gregL, GreyFoxx, Guest37385, IReboot, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe___, joki, jpabq, jpharvey, jst, jwhite, kc, kenni, Kevin`, knightr, kurre2, kwmonroe, laga, monkeypet, Mousey, mrand, MythBuild, MythLogBot, neufeld_AFK, NightMonkey, Peitolm, peper03, Peps, petefunk_, poptix, purserj, rsiebert, Seeker`, seld, Sharky112065, skd5aner, sl1ce, Slasher`, SmallR2002, sphery, sraue, stuarta, superm1, sutula, taylorr, tgm4883, toeb, tonsofpcs, tris, Vernon_at_work, wagnerrp, wahrhaft, wolfgang1, xavierh_, XDS2010__, yoyolala, _charly_
Tuesday, December 11th, 2012, 00:00 UTC
[00:00:42] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[00:05:31] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has quit (Ping timeout: 255 seconds)
[00:11:54] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Read error: Connection reset by peer)
[00:11:58] stuartm_ (stuartm_! has joined #mythtv
[00:11:58] stuartm_ (stuartm_! has quit (Changing host)
[00:11:58] stuartm_ (stuartm_!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[00:13:27] stuartm_ is now known as stuartm
[00:15:59] sl1ce (sl1ce! has quit (Quit: Konversation terminated!)
[00:19:06] sl1ce (sl1ce! has joined #mythtv
[00:19:30] Jordack (Jordack! has quit (Read error: Connection reset by peer)
[00:20:46] Jordack (Jordack! has joined #mythtv
[00:20:55] Wolfgang2 (Wolfgang2! has quit (Quit: Wolfgang2)
[00:38:06] PatrickDickey (PatrickDickey!~quassel@2001:470:1f11:830:b197:ad23:a7bf:696e) has quit (Remote host closed the connection)
[00:39:38] ekristen (ekristen! has joined #mythtv
[00:40:54] jheizer_laptop (jheizer_laptop! has quit (Ping timeout: 264 seconds)
[00:44:12] ekristen (ekristen! has quit (Ping timeout: 252 seconds)
[00:49:29] garybuhrmaster (garybuhrmaster! has left #mythtv ()
[00:54:08] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[00:56:39] Jordack (Jordack! has quit ()
[00:58:33] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 244 seconds)
[01:26:34] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[01:48:30] Seeker` (Seeker`!~cjo20@unaffiliated/seeker) has joined #mythtv
[01:50:18] Mousey: ok internets.. that's enough outta me for today!
[01:50:26] Mousey (Mousey! has quit (Remote host closed the connection)
[01:52:05] mrand (mrand!~mrand@ubuntu/member/mrand) has joined #mythtv
[02:26:30] zombor (zombor!~zombor__@ has joined #mythtv
[02:26:31] zombor (zombor!~zombor__@ has quit (Changing host)
[02:26:31] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[02:30:38] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Read error: Operation timed out)
[02:38:24] jya: ready for committing the ffmpeg resync… I have some questions on the best way to proceed. I can commit just the ffmpeg files , followed by all the changes required in the myth code
[02:38:30] jya: or commit all at once…
[02:39:57] danielk22: jya: With svn the idea was to commit it all at once, but I think with git it makes more sense to just push it all at once and keep the two (or more) commits separate.
[02:40:52] jya: the only thing against the two commits, is should you do a git bisect, you may end up with a code that do not compile (say you revert only the change to the myth code)
[02:41:52] danielk22: jya: yep, but if you are bisecting you often need to move forward or back a commit anyway so it's not that bit a deal.
[02:41:52] rsiebert (rsiebert! has joined #mythtv
[02:42:35] jya: ok… very well… I've done it in a branch currently… But what interest me the most is seeing if I break any automatic build. I can only test linux + mac...
[02:42:47] jya: and with branch, they aren't build automatically
[02:43:46] danielk22: The mingw builder is down at the moment, so you'll really just gain freebsd & the various distro's.
[02:45:04] danielk22: btw $ git bisect skip # for skipping untestable versions
[02:45:06] rsiebert_ (rsiebert_! has quit (Ping timeout: 264 seconds)
[02:46:24] jya: I'm sure there are more stuff broken…. I only focused at audio stuff, testing all the media I had… there's probably more stuff… This change to planar data was a pain, especially as they even changed how planar data was stored between now and 6 months ago
[02:49:54] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 240 seconds)
[02:52:17] stuartm (stuartm! has joined #mythtv
[02:52:17] stuartm (stuartm! has quit (Changing host)
[02:52:17] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[02:55:49] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[03:17:19] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[03:29:37] jya: hum… trying to push my new branch and I get: remote: C refs/heads/resync.92f630eaf21 mythtv jyavenard DENIED by fallthru
[03:29:38] jya: remote: error: hook declined to update refs/heads/resync.92f630eaf21
[03:29:39] jya: To :mythtv
[03:29:39] jya: ! [remote rejected] resync.92f630eaf21 -> resync.92f630eaf21 (hook declined)
[03:29:53] jya: hook declined… what does that mean?
[03:32:44] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds)
[03:32:51] jya: Beirdo: ^^
[03:32:58] Sharky112065 is now known as Sharky-AFK
[03:38:43] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[03:46:01] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[03:57:27] stichnot (stichnot! has joined #mythtv
[03:57:27] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[03:57:27] stichnot (stichnot! has quit (Changing host)
[03:58:21] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:06:56] Beirdo: invalid branch name
[04:10:10] waynemcdougall (waynemcdougall! has quit (Ping timeout: 256 seconds)
[04:13:50] jya: Beirdo: what's a valid name then?
[04:14:02] Beirdo: devel/resync
[04:14:08] jya: I renamed the branch to resync_92xxx
[04:14:10] jya: same error
[04:14:25] Beirdo: **devel/**
[04:14:37] jya: I see
[04:14:48] xris: think of it as a directory structure. top level stuff is only for releases and a couple of categories (e.g. devel or personal)
[04:15:18] Beirdo: otherwise the permissions are nearly impossible to maintain in a sane way
[04:15:22] jya: danielk22: I see other issues with your change of += vs *=
[04:16:02] jya: I compile with --extra-cxxflag="-D blah -D foo"
[04:16:06] jya: it removes one of the -D
[04:16:16] jya: ok… here I can just type -Dblah
[04:17:21] Beirdo: gonna have to go start a load of laundry... flight across the continent Wed morning ;)
[04:17:35] xris: I think the no-space variation is actually more correct (or seems to be more used)
[04:21:10] jya: xris: there are other stuff breaking my build here (plain gcc) trying to identify which commit
[04:22:22] xris: ah
[04:22:40] xris: plus you should never take any c++/gcc advice from me because I don't actually know anything about it.  ;)
[04:22:41] jya: xris: all I'm pointing out really, is that qmake *= is fundamentally broken whenever you want to pass arguments using a pair
[04:22:56] xris: or qmake. heh
[04:23:15] jya: if you do something like --arg blah --arg blah2
[04:23:21] jya: it removes one of the --arg
[04:25:56] Beirdo: you had me at "qmake is fundamentally broken" :)
[04:26:13] xris: yeah, I gathered that from your earlier statement.. seems shortsighted and stupid.
[04:40:03] jya: ok… now to find how to identify which part of the May resync broke it …..
[04:46:59] aaas (aaas! has joined #mythtv
[04:49:25] aaas: where can i check/change the settings for connections such as connecting port (def: 6543)
[04:55:18] xris: aaas: first, ask in the user channel, not the dev channel.  :)
[04:56:10] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[04:59:30] jhezer_ (jhezer_! has joined #mythtv
[04:59:39] jhezer_ is now known as jheizer_laptop
[05:00:33] aaas: oops sorry
[05:00:52] aaas (aaas! has left #mythtv ("Closing Window")
[05:06:32] jheizer_laptop: SOB I finally logged in here to ask where the ID being used in mythweb comes from when you click on a program
[05:06:38] jheizer_laptop: epoch
[05:06:52] jheizer_laptop: Will admit it took me too long to figure that out
[05:07:44] jheizer_laptop: trying to make use of mythweb pages in my Web FE for recording features for now
[05:07:49] sl1ce (sl1ce! has quit (Remote host closed the connection)
[05:09:02] sl1ce (sl1ce! has joined #mythtv
[05:15:07] sl1ce (sl1ce! has quit (Quit: Konversation terminated!)
[05:17:18] sl1ce (sl1ce! has joined #mythtv
[05:36:02] waynemcdougall (waynemcdougall! has joined #mythtv
[05:39:40] jya: ok… I've pushed devel/resync if you guys could do some basic testing….
[05:39:42] jya: Thanks
[05:50:20] stichnot: jya: building now
[05:50:28] jya: great thanks
[05:51:06] jya: hum… VDA isn't detected on my mac
[05:52:57] jya: oh, actually, I was on master…
[06:00:27] stichnot: jya: no change in the bad behavior of the clip from #10622
[06:00:27] ** MythLogBot **
[06:00:46] jya: :(
[06:01:09] jya: not sure where the seektable would come into account with ffmpeg though
[06:01:49] jya: more likely improper use of ffmpeg API if you ask me
[06:03:33] stichnot: running "ffmpeg -i colbertclip.mpg" on my system gives the "correct" output, i.e. 4 streams detected. mythffmpeg detects only 2 streams like before
[06:03:56] stichnot: and my ffmpeg version says:
[06:04:01] stichnot: ffmpeg version 0.8.4–4:0.8.4–0ubuntu0.12.04.1, Copyright (c) 2000–2012 the Libav developers
[06:04:03] stichnot: built on Nov 6 2012 16:51:33 with gcc 4.6.3
[06:05:15] jya: interesting...
[06:05:31] jya: you sure the mythffmpeg is a new build ?
[06:05:47] jya: don't even know if it's build using that name
[06:05:56] jya: may have been built as ffmpeg
[06:07:15] jya: stichnot: is it a mpegts file ?
[06:07:23] stichnot: timestamp seems the same as the other binaries
[06:07:26] jya: myth uses its own demuxer there
[06:07:45] stichnot: not sure, how would I tell?
[06:07:56] jya: what file are you trying to play?
[06:08:17] stichnot: a sample provided in the ticket, colbertclip.mpg
[06:08:31] jya: sounds like a mpeg-ts
[06:09:12] jya: that would be using mpegts-mythtv.c
[06:09:28] stichnot: interesting
[06:09:32] jya: and not the ffmpeg's own demuxer (which is rename mpegts-ffmpeg)
[06:09:45] stichnot: the clip in the ticket is still available,btw
[06:10:23] jya: I don't believe any change would have been made to myth one in years, all I did last time is renamed it so we don't have to do manual merging
[06:10:52] jya: let me wrap a quick patch for you to try (that make it use ffmpeg's own demuxer
[06:11:14] Sharky-AFK is now known as Sharky112065
[06:15:00] stichnot: I have to step out for ~30 minutes
[06:23:18] jya: stichnot: try this:
[06:23:38] jya: I too must step out now… see how you go with that. this is using ffmpeg's original mpegts demuxer
[06:24:14] jya: the kind of bug I'm sure janne would have spent only 5' to fix
[06:25:54] jheizer_laptop (jheizer_laptop! has quit (Ping timeout: 264 seconds)
[06:41:10] lvmer (lvmer! has quit (Quit: Leaving.)
[06:55:36] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[06:56:59] ekristen (ekristen! has joined #mythtv
[06:57:11] ekristen (ekristen! has quit (Remote host closed the connection)
[06:57:37] ekristen (ekristen! has joined #mythtv
[06:59:08] stichnot: jya: the patch changes behavior but doesn't fix it. The duration is now displayed as 11 hours 52 minutes as indicated in the ffmpeg/mythffmpeg output, instead of hundreds of hours or whatever was before. It plays about 2 seconds before exiting, with a slew of log messages about AV-Sync might be broken followed by more about waiting for video buffers.
[06:59:10] SteveGoodey (SteveGoodey! has joined #mythtv
[07:00:34] stichnot: ffmpeg and mythffmpeg seem to detect fundamentally the same track info though the specific output is curiously different
[07:03:35] stichnot: I wonder if there is any relationship between this issue and the problems with live TV that users have been reporting with 0.26
[07:05:43] jarryd: the git version of mythweb should work with php 5.4, right?
[07:10:34] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[07:13:20] stichnot: sphery: I just pushed a commit that removes the DispRecGroupAsAllProg setting and unconditionally names the topmost group "All Programs", in conjunction with a fix that lets the themer label the screen with something like "Watch Recordings – <group_filter>". The "All Programs" label seems to be in contradiction with what you wrote in the thread
[07:13:21] stichnot: 29315#529315 , though the idea of adding the group filter to the Watch Recordings string wasn't mentioned. Any thoughts on this?
[07:13:37] stichnot: Nice truncation — try
[07:13:59] stichnot: (Either way, it's one less setting, right? :) )
[07:20:58] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[08:05:41] ekristen (ekristen! has quit (Read error: Connection reset by peer)
[08:06:00] ekristen (ekristen! has joined #mythtv
[08:06:58] wahrhaft (wahrhaft! has quit (Read error: Connection reset by peer)
[08:07:11] wahrhaft (wahrhaft! has joined #mythtv
[08:07:49] IReboot (IReboot! has quit (Ping timeout: 248 seconds)
[08:08:15] IReboot (IReboot! has joined #mythtv
[08:09:00] dekarl (dekarl! has quit (Ping timeout: 255 seconds)
[08:09:25] danielk22 (danielk22!~danielk@ has quit (Ping timeout: 248 seconds)
[08:09:55] J-e-f-f-A (J-e-f-f-A! has quit (Excess Flood)
[08:10:26] J-e-f-f-A (J-e-f-f-A! has joined #mythtv
[08:10:38] danielk22 (danielk22!~danielk@ has joined #mythtv
[08:12:10] jya (jya! has joined #mythtv
[08:12:10] jya (jya! has quit (Changing host)
[08:12:10] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:13:08] dekarl (dekarl! has joined #mythtv
[08:15:12] jya: stichnot: with the patch apply, does mythffmpeg now reports the same info as stock ffmpeg ?
[08:16:45] jya: I have that issue of "waiting for video buffers" on my avi file when using SG… used as a local file, it doesn't occur
[08:37:39] waynemcdougall (waynemcdougall! has quit (Remote host closed the connection)
[08:52:43] Guest9279 (Guest9279! has quit (Read error: Connection reset by peer)
[09:03:12] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7897:b67f:d9d3:ed62) has joined #mythtv
[09:19:24] seld (seld! has quit (Ping timeout: 265 seconds)
[09:19:53] anykey_ (anykey_! has quit (Ping timeout: 265 seconds)
[09:20:23] anykey_ (anykey_! has joined #mythtv
[09:20:39] seld (seld! has joined #mythtv
[09:45:51] stuarta: jya: if you need the builders to point to a branch for a while just ask
[10:11:16] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[11:21:48] jya (jya! has joined #mythtv
[11:21:48] jya (jya! has quit (Changing host)
[11:21:49] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[11:44:36] Sharky112065 is now known as Sharky-AFK
[11:54:03] Weaselweb (Weaselweb! has joined #mythtv
[11:55:26] Weaselweb: hello. I noticed that some entries in my video list are sorted slightly different than I would expect. it seems sorting ignores any starting aticle (like "das", "die", etc. which are pretty common in german title). is there any option to change that?
[12:00:38] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[12:02:45] stuartm: Weaselweb: we handle that for English and I think Japanese but not currently German – you should speak to our translation team, knightr or kenni
[12:04:09] Weaselweb: stuartm: mh, ok. is it possible that some inconsistency is caused from upgrades during severy myth version?
[12:04:11] stuartm: Weaselweb: sorry mis-read, ignoring the article is standard, there is no way to change that behaviour. It's normal to ignore the article in English and some other languages, if it's not correct for German we can change it
[12:04:39] Weaselweb: ic. dunno if this is standard in German or not
[12:06:44] stuartm: in English we'd ignore The, A or An when sorting
[12:09:35] Weaselweb: ok, I noticed it last days in a directory where lots of movies have aticles at the beginning. I check if that sort order is present also for other movies
[12:18:53] jya: stichnot: I'm currently running 0.25 ; and your video shows 466hours long...
[12:19:05] jya: are you sure this is a problem that start in 0.26 only?
[12:26:47] IReboot (IReboot! has quit (Remote host closed the connection)
[12:27:44] IReboot (IReboot! has joined #mythtv
[12:32:00] jya: stichnot: sounds like the problem is more related to a change on how to detect the length of a video than anything else. didn't you change something on that code a while back (before 0.25) ?
[12:48:27] ekristen (ekristen! has quit (Quit: ekristen)
[12:50:43] knightr: stuartm, Weaselweb It ignoring those articles is not OK I can ask Florian to change that but currently the German translation ignores Der, Die, Das, Ein, Eine + The, A, An. We have a nice comment/disambiguation string that let the translator know what these are used for so he filled those in on purpose not by mistake.
[12:55:24] jya: stichnot: actually, it seems that value read is from the database, reverting partially 53663999b09a4f7c4a3b67edf2dcdf08f170d761 (Beirdo mod that check if the duration of a file is stored in the database). For your video here I get 11h+ instead of 400+
[13:07:26] jya: also, 3924df87c7691852741b596f50311eac46f930ab (danielk22) and ebf194444c30eb6c7d1d6d272045674fc45a2e65 (Captain_Murdoch) when I revert this, along 53663999b09a4f7c4a3b67edf2dcdf08f170d761. I get the time estimate not showing crazy times on the video of #10622
[13:07:26] ** MythLogBot **
[13:07:46] jya: it's my guess that everyone having a try at this thing, has only made things worse
[13:09:50] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[13:10:23] ** jya off to be **
[13:10:25] jya: d
[13:15:30] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[13:21:20] Sharky-AFK (Sharky-AFK! has quit (Quit: “The only way to have a friend is to be one.” ― Ralph Waldo Emerson)
[13:41:02] Sharky-Sleep (Sharky-Sleep! has joined #mythtv
[13:41:23] Sharky-Sleep is now known as Sharky-AFK
[13:47:21] sphery: stichnot: I saw your commit message and it sounded good... I had envisioned that it would say All Programs when no filter is applied and would say the filter name when a filter is applied (so users always know what they're looking at--all programs or a filtered list of "Movies" or "Drama" or whatever). Is that what you did or are you saying it always says "All Programs" no matter what?
[14:18:07] stichnot: sphery: What I implemented is as though DispRecGroupAsAllProg=0 (i.e., "don't display the current recording group as the All Programs text"). Partly because that's how my systems are configured, and partly because that seemed to be the consensus of the discussion . Though it's possible that there were different conclusions in the latter...
[14:18:09] stichnot: ...part of the discussion that didn't get logged.
[14:20:43] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[14:20:47] stichnot: Regardless, once the dust settles, I'll send a note to the -theming list recommending adding the group filter to the text of the "Watch Recordings" screen.
[14:21:36] SmallR2002 (SmallR2002! has quit (Ping timeout: 240 seconds)
[14:22:49] SmallR2002 (SmallR2002! has joined #mythtv
[14:24:19] Sharky-AFK is now known as Sharky112065
[14:25:18] stichnot: jya: you're right, ticket 10622 is clearly with respect to 0.25 not 0.26
[14:25:54] Jordack (Jordack! has joined #mythtv
[14:29:27] gregL (gregL! has quit (Quit: Leaving)
[14:29:50] gregL (gregL! has joined #mythtv
[14:34:08] sphery: stichnot: I'm ok with the current, but only if the filter name is always shown elsewhere on the screen--the whole problem with the current is that users enable filters and have no idea (and no indicator), so they think they lost a bunch of recordings.
[14:35:00] sphery: I just assumed we'd change the group name since I thought that's the only thing we can be sure will be on the screen, but if there's another way.
[14:35:03] danielk22: jya: I'm not sure why the CFLAGS are getting applied twice with the +=, if we can figure that out we don't need the *=
[14:35:56] stichnot: jya: Part if not all of the problem is about determining the length of the video. If you get it from the DB (as a result of either the 0.25 recorder inserting the length or mythcommflag --rebuild inserting the length), everything is fine. The regression seems to have been to do with how ffmpeg determines the length in the absence of DB info.
[14:39:05] danielk22: The ffmpeg length calculation is fundamentally broken. It is based on the dts/pts values at the beginning and end of the recording and there can be discontinuities at multiple points in the recording.
[14:39:27] stichnot: sphery: The problem with my current implementation is that we can't force all themers to display the filter. My personal preference is to look for the string "All Programs" (regardless of the group filter in place) as a synonym for "beginning of list", and I find it a bit jarring to see different text there.
[14:40:23] stichnot: Another approach is to display "All Programs – <filter>" instead of "All Programs" or "<filter>"
[14:41:18] danielk22: jya: stichnot: Those discontinuities are also causing problems for the recording quality determination. gigem uploaded a file for me to look at the discontinuity problem for recording quality, that could be used to test the length calculations too.
[14:42:32] danielk22: The old way we did it was by taking the frame count and dividing by the framerate, but this gave bogus too because the framerate can change during the recording.
[14:44:43] joki (joki! has quit (Ping timeout: 244 seconds)
[14:45:08] danielk22: We could solve this by storing either frame-rate or dts/pts discontinuities in the DB and then adding up the sums of all the calculated lengths, or by simply storing wall clock time at various points in the stream. But these seem too complicated to implement for this minor feature..
[14:46:21] danielk22: For just the recording duration we could also just use the recording start and recording end times, but that won't help for the current position in the recording for the OSD.
[14:46:42] stichnot: I thought at some point that taylorr was going along those lines
[14:47:02] joki (joki! has joined #mythtv
[14:47:48] danielk22: I think he got frustrated by the complexity of it. This feature has suffered from a lot of ppl going in and thinking "this simple fix will make all my recordings show the correct time"
[14:49:56] stichnot: It's not all that complicated to make use of the segment information for mapping a frame to its display time or mapping a display time to its frame – I'm essentially doing that when applying the cutlist. And btw a cut region can be treated as a region with an infinite frame rate.
[14:50:36] stichnot: The only challenge (in my mind) is to get the segment information reliably into the DB.
[14:51:22] danielk22: stichnot: If you write the segment mapping code I can easily add the segment info to the DB.
[14:51:46] danielk22: We're already tracking pts/dts discontinuities for the RecordingQuality class.
[14:57:21] stichnot: danielk22: The segment mapping code would be an extension of DeleteMap::TranslatePositionAbsToRel() and DeleteMap::TranslatePositionRelToAbs(). Segment info would have to include changes in frame rate. I'm not sure I would have a use for pts/dts values.
[14:57:23] danielk22: I'm not sure if a pts/dts would fit in the 'data' in a the recordedmarkup. For practical purposes it is a 34 bit number (unless a recording goes over 26 hours!) since ffmpeg won't roll over the pts/dts to 0 when it exceeds 33 bits.
[14:57:58] danielk22: Ok, so track it would be more useful to frame rate changes not pts/dts?
[14:58:30] danielk22: err "Ok, so tracking frame rate changes is better than pts/dts?"
[14:58:43] stichnot: I believe so, but let me think a bit more
[14:59:11] stichnot: At least one more issue is the repeated_pict aspect
[15:00:10] stichnot: I have some older discussions with taylorr that I need to reread
[15:02:11] stichnot: but even with full segment info, we still ought to deal with recordings/videos that lack DB info, such as legacy recordings and Video Library insertions
[15:02:26] danielk22: I think those get counted as 30fps even though there are only 24 actual frames per second.
[15:03:59] dmfrey (dmfrey! has joined #mythtv
[15:04:41] Sharky112065 is now known as Sharky-Sleep
[15:04:58] danielk22: My thinking is when given a file that is a complete unknown we just assume it's framerate is whatever it starts out as, but we also have import functionality for the video library where we run mythcommflag --rebuild on those recording as a housekeeper task and mark them up.
[15:07:45] danielk22: stichnot: looking at recorder base it looks like we are already saving framerate changes to the recorded markup table..
[15:10:19] stichnot: danielk22: is the file from gigem on the box site? I didn't see it there
[15:10:29] stuarta: danielk22: i think tracking pts/dts discontinuities and then calculating based upon pts/dts should work.
[15:10:43] danielk22: It's recorded with the frame as the mark, type of MARK_VIDEO_RATE, and 'framerate' in data. It looks like it only captures some standard framerates (see frameRateMap in dtvrecorder.cpp).
[15:10:51] stichnot: I think I have recordings with repeated_pict but I'm not sure I have ones with changing frame rates or discontinuities
[15:11:24] danielk22: stichnot: you can just cat a few short mpegs together :)
[15:15:45] danielk22: stichnot: I can't find it ATM. It looks like it is not on
[15:17:06] Goga777 (Goga777! has joined #mythtv
[15:17:47] danielk22: I want to look at gigem's because his are coming from the cable co with discontinuities, so they are probably flagged properly.
[15:17:58] jhezer_ (jhezer_! has joined #mythtv
[15:18:38] stichnot: danielk22: can you really cat mpegs together?
[15:21:17] danielk22: yep. It's a very resilient container
[15:22:48] danielk22: When I was working on the video playback long ago I used files with various random short recordings catted together to test the player and ffmpeg syncs.
[15:24:38] wagnerrp: playback works fine, but seeking can be an issue
[15:24:43] wagnerrp: due to discrepancies in time codes
[15:25:04] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7897:b67f:d9d3:ed62) has quit (*.net *.split)
[15:25:04] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (*.net *.split)
[15:25:14] danielk22: wagnerrp: But if you have a seek map it's not bad.
[15:25:26] stichnot: Very cool. I think I can just alternate 720p/1080i/SD clips for testing
[15:25:44] wagnerrp: right, less of an issue in mythtv than most other players
[15:25:49] wagnerrp: since it doesn't use the timecodes
[15:26:10] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7897:b67f:d9d3:ed62) has joined #mythtv
[15:26:10] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv
[15:27:17] gigem: stichnot: The link is . If that turns out to not be a good sample, let me know. I can get more. I can also get lots of examples of frame rate changes since Verizon's local commercials are always interlaced even on normally progressive channels.
[15:30:35] stichnot: gigem: thanks, I got it, I'll study it later.
[15:30:54] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7897:b67f:d9d3:ed62) has quit (*.net *.split)
[15:30:55] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (*.net *.split)
[15:32:06] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7897:b67f:d9d3:ed62) has joined #mythtv
[15:32:06] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv
[15:50:23] Weaselweb (Weaselweb! has left #mythtv (" - Chat comfortably. Anywhere.")
[15:50:35] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 256 seconds)
[15:53:50] superm1 (superm1!uid4318@ubuntu/member/superm1) has quit (Remote host closed the connection)
[15:53:50] XDS2010__ (XDS2010__!uid1218@gateway/web/ has quit (Remote host closed the connection)
[16:17:33] gigem: stichnot, danielk22: I got around to running dvbsnoop on the timing example I uploaded. It does appear to set the discontinuity_indicator flag.
[16:23:17] XDS2010__ (XDS2010__!uid1218@gateway/web/ has joined #mythtv
[16:29:30] danielk22: gigem: That's great, I can incorporate that into the RecordingQuality algorithm.
[16:31:26] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[16:33:36] superm1 (superm1!uid4318@ubuntu/member/superm1) has joined #mythtv
[16:33:43] stichnot (stichnot!~stichnot@ has joined #mythtv
[16:33:45] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:33:45] stichnot (stichnot!~stichnot@ has quit (Changing host)
[16:44:36] jhezer_ (jhezer_! has quit (Ping timeout: 248 seconds)
[16:45:35] stichnot: jya: I just noticed that mplayer and vlc both don't do well with colbertclip.mpg, so I guess I don't know how much time should be spent chasing this particular sample
[16:46:45] jhezer_ (jhezer_! has joined #mythtv
[16:50:37] stichnot: gigem: is your sample just demonstrating pts/dts discontinuities, or are there any changes in resolution/framerate/etc?
[16:56:14] jhezer_ (jhezer_! has quit (Ping timeout: 252 seconds)
[16:56:54] stichnot: What problems are we potentially blaming the 0.25 ffmpeg for? Getting the elapsed time is one. I think some mythcommflag crashes are another. Anything else?
[16:57:08] Goga777 (Goga777! has quit (Remote host closed the connection)
[17:06:17] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 244 seconds)
[17:09:38] gigem: danielk22: That sample only shows pts/dts discontinuities. If you want, I can get you a sample with framerate (and maybe resolution) changes tonight.
[17:10:22] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:20:06] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:35:59] stichnot: danielk22: How does the recorder keep track of pts/dts/framerate/etc without risking an ffmpeg segfault on unclean input?
[17:48:33] danielk22: stichnot: It doesn't use ffmpeg :)
[17:49:12] stichnot: OK, so I assume it does not have access to repeat_pict info, right?
[17:51:20] danielk22: We don't parse that yet. But I don't expect it to be any more difficult than grabbing the pts/dts.
[17:59:10] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:7897:b67f:d9d3:ed62) has quit (Read error: Connection reset by peer)
[18:01:49] stichnot: danielk22: I think that I would want to treat the recording as broken down into contiguous sequences of (frame_rate, frame_count, repeat_pict_count) and I would assume that the repeat_pict instances are uniformly distributed across the sequence.
[18:06:25] stichnot: That should be enough information to translate back and forth between frame number and zero-based timestamp. I think that original pts/dts can be completely ignored during playback.
[18:09:10] Mousey (Mousey! has joined #mythtv
[18:16:02] SteveGoodey (SteveGoodey! has joined #mythtv
[18:16:43] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[18:17:03] gregL (gregL! has quit (Read error: Connection reset by peer)
[18:20:23] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[18:32:28] stichnot: We would need to deal with live TV or in-progress recordings, and (as usual) try to do something sane in the absence of markup info in the DB.
[18:44:20] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[19:41:49] dmfrey (dmfrey! has quit (Remote host closed the connection)
[19:43:00] gregL (gregL! has joined #mythtv
[19:46:31] dmfrey (dmfrey! has joined #mythtv
[20:08:37] ekristen (ekristen! has joined #mythtv
[20:11:14] ekristen_ (ekristen_! has joined #mythtv
[20:11:26] ekristen_ (ekristen_! has quit (Client Quit)
[20:13:08] ekristen (ekristen! has quit (Ping timeout: 248 seconds)
[20:20:24] peper03 (peper03! has joined #mythtv
[20:33:34] Lomion_Tablet (Lomion_Tablet! has joined #mythtv
[20:48:22] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Ping timeout: 245 seconds)
[20:59:14] Lomion_Tablet (Lomion_Tablet! has quit (Quit: AndroIRC - Android IRC Client ( ))
[21:01:48] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[21:09:28] stichnot: Oh, and "in the absence of markup info in the DB" includes DVD/BD playback. That may make things more complicated. I wonder how often DVDs have dts/pts discontinuities.
[21:09:30] taylorr: stichnot: I have a patch that calculates the duration of each frame by the recorder – it uses repeat pict
[21:09:42] taylorr: I believe I sent it to you a long time ago
[21:10:57] danielk22: stichnot: I would expect DVD/BD's to have very few discontinuities. But maybe at chapter boundaries if it is one of those discs that optionally shows missing scenes.
[21:11:19] stichnot: taylorr: ah yes, I do have that.
[21:12:03] taylorr: danielk22: I didn't get frustrated by the complexity of the proper solution... it was frustrating until I figured that part out
[21:12:09] danielk22: Most discontinuities are at splice points, or when a broadcaster switches from primary to backup, or when there is an outage.
[21:12:54] danielk22: taylorr: So you just ran out of time? I wasn't sure why you stopped working on it.
[21:14:27] taylorr: yep... the solution should be quite elegant and simple.. just needs to be implemented... part of it's done
[21:14:28] peper03: stichnot: DVDs often lots of discontinuities in the menus because playback tends to jump around a lot even if it isn't always obvious (e.g. a clip leading into the menu, a clip under the menu). This doesn't *always* happen, but quite often. Whether that's a problem or not, I don't know.
[21:14:50] peper03: s/often lots/often have lots/ :)
[21:15:48] taylorr: danielk22: no need to track discontinuities, wall time or pts... mainly just need to look at each frame as the recorder writes it and calculate it's duration... we get the frame rate updates and repeat_pict values so we have everything we need to do this accurately and simple
[21:16:05] taylorr: we basically already do this in the commercial flagger, but at a higher level
[21:17:00] taylorr: I have a patch that does the frame duration calculation and accumulates the total... just need to write to database when recording is finished
[21:17:15] taylorr: then the player can pull this for duration and position calculations
[21:18:18] danielk22: taylorr: The total time isn't really the difficult part, it's answering "at what time is frame 13224 within this 1 hour recording" for the OSD, that needs the segment map.
[21:18:24] stichnot: taylorr: what you described to me in email was to figure out the average fps across the entire recording, which would make time display and seeking approximate but consistent. You also described a variation where you make it much more accurate by tracking this on a keyframe basis.
[21:18:43] Steve-Goodey (Steve-Goodey! has joined #mythtv
[21:18:55] taylorr: danielk22: it's on difficult if you want to be exact... I don't think that's necessary
[21:18:57] danielk22: Or answering "at what frame # is 43:23.20"
[21:19:20] stichnot: danielk22: and the inverse – "which frame is at the 30-minute mark?"
[21:19:27] stichnot: yeah, what you said :)
[21:20:26] stuartm: peper03: another DVD that stutters with vdpau is Treme Season 2, Disc 1 – HBO ident and menu both affected
[21:20:55] stuartm: navigating to the menu, even while in the menu fixes it
[21:21:01] taylorr: yes, getting exact is taking things to another level, but the base of the solution is still the same in that the recorder keeps track of duration and frame count... if you want to store more info in the markup for more exact processing then that's possible too
[21:21:20] stuartm: peper03: I guess I can debug this one myself :)
[21:22:12] peper03: stuartm: Never even *heard* of Treme, let alone the fact that there's more than one season :)
[21:22:16] stuartm: heh, this DVD is going to expose all the problems, wrong audio track is selected too
[21:22:38] len (len! has joined #mythtv
[21:22:55] len is now known as Guest37385
[21:22:59] stichnot: taylorr: If I have a 60-minute recording where 40 minutes is the actual show at 60fps and 20 minutes is commercials at 30fps, I have a feeling I won't like the experience of taking the average frame rate across the entire recording. So I prefer your more-precise suggestion which is basically segmenting at the keyframe level.
[21:23:00] stuartm: and commentary tracks aren't identified
[21:23:52] stuartm: guess I won't be putting this in the post tomorrow :(
[21:23:58] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[21:24:18] stichnot: To get *really* exact, one would have to keep a complete map of repeat_pict frame, but I assume those will always be uniformly distributed across the segment.
[21:24:45] peper03: stuartm: I've got one like that too. 'Paul' bombs out after selecting 'Play' in the main menu (#11276 fixes that) and the commentary track is selected instead of the normal 5.1 track.
[21:24:45] ** MythLogBot **
[21:24:49] taylorr: stichnot: sure, so basically you'll need to add a timecode in addition to the byte position for the markup table
[21:25:46] taylorr: stichnot: some may object to adding extra info into the markup table... dunno
[21:25:52] peper03: stuartm: I had a quick look at the audio track problem. It seems (and it was only a quick look at something I don't really know) that ffmpeg was returning -1 as the audio stream for the commentary track. That screwed up the sorting.
[21:26:07] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[21:26:11] taylorr: sticnot: shouldn't make it that much bigger though
[21:26:13] danielk22: I think the segmented solution at the fps changes would be sufficient for a good user experience. And from my reading of the code we're already putting those in the DB..
[21:26:49] taylorr: we keep track of fps changes in relation to keyframes in the database already?
[21:27:22] taylorr: you would need to know the timecode at the start of the segment too
[21:27:52] taylorr: I think you will still need to have the timecode at each keyframe
[21:28:00] stichnot: taylorr: I assume I'd have 3 extra marks for each segment: frame_rate, frame_count, and repeat_pict_count. I would expect at most 15 segments for a 1-hour recording, so it's not much extra data.
[21:28:33] taylorr: ok, I think I understand what you guys are cooking up
[21:28:36] stichnot: To determine the display time for a given frame, you'd have to sum up the info for all prior segments
[21:28:59] taylorr: should work, probably would be easier to implement if you just stored the timecode of each keyframe though
[21:29:07] danielk22: I believe so. I looked at the code this morning, see RecorderBase::FrameRateChange(). I know how long it's been there and we'd want to add this to the commflagger too & check that this is actually getting updated...
[21:29:24] stuartm: AFD: Selected track 1: English AC3 5.1ch (A/V Stream #7) << Track one is stream 3, stream 7 is track 5 – this is all correctly identified and logged immediately prior
[21:29:24] ** MythLogBot **
[21:29:42] stuartm: stream 7 isn't even 6 channel, it's stereo
[21:30:12] stuartm: at least that narrows it down considerably
[21:30:31] taylorr: stichnot, danielk22: ok, sounds like guys have moved way ahead of were I was going which sounds good... let me know if you have any questions
[21:31:06] stichnot: taylorr: this is basically just a half day of brainstorming :)
[21:31:25] taylorr: right, the devil is in the details
[21:32:33] taylorr: I usually just go with the easiest approach which would be storing the timecode at every keyframe... but that might not be prudent if the markup tables get too big
[21:32:55] taylorr: people with 10,000 recordings might not like it :)
[21:33:07] stichnot: taylorr: This is fine for new recordings or old recordings updated with mythcommflag --rebuild. But I don't know a good approach for other videos, such as DVDs, where we don't have any of this markup, and we may have changing frame rates, repeat_pict frames, pts/dts discontinuities, etc.
[21:33:45] taylorr: stichnot: with DVDs you can rely on the pts
[21:34:10] stichnot: taylorr: I have 2500 recordings, so if it works for me... :)
[21:34:12] taylorr: never heard of a dvd with discontinuites
[21:34:35] danielk22: taylorr: even if it is one of those DVD's that have different cuts (with and without deleted scenes) ?
[21:34:54] taylorr: if dvd players can handle this without a markup table then so should we
[21:35:13] taylorr: maybe peper03 know :)
[21:36:16] danielk22: With DVD's each chapter could be a segment in a segment map. But I really know very little about how we stitch these together.
[21:37:01] taylorr: stichnot: you only have to worry about MPEG-PS/TS formats... I'm now aware of any other formats that support discontinuities.... so avi, mkv, mp4, etc should all be straight forward
[21:38:04] peper03: taylorr: I've not looked too closely at it. Mainly when I was trying to get menu highlights to appear at the right time (must look at that again at some point). I did see some continuitiy jumps but in the menus it's jumping all over the place, and sometimes there are stills, which introduce other problems.
[21:38:22] peper03: I've certainly not looked at it at the MPEG level.
[21:39:31] taylorr: I don't think we need to worry about the duration/position of dvd menus... just when playing back the titles
[21:40:39] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[21:41:12] stichnot: For a DVD without a segment map, if I want to jump to the 30-minute mark, I could do a binary search of seeks until I find the right timecode (relative to the timecode of the first frame), right? Is there anything simpler?
[21:42:43] peper03: taylorr: Sure. Just wanted to point out that it can occur. There is an event that comes from libdvdnav that the (minimal) documentation specifically mentions it should be used to detect discontinuities.
[21:46:41] peper03: stichnot: That already seems to be handled by libdvdnav. There's a method in DVDRingBuffer ('Seek' with single parameter) that jumps to a given time.
[21:48:08] peper03: stuartm:
[21:48:47] peper03: stuartm: Seems to be a similar problem. It's choosing stream 7 thinking it's 5.1 but it's not.
[21:48:48] stichnot: peper03: I see. I could only see a problem with that if DVDs were allowed to have cutlists.
[21:49:53] stichnot: danielk22: Along these lines, there is a ticket #10584 claiming that the recorder, mythcommflag, and mythtranscode can come up with different keyframe indexes on the same input file.
[21:49:53] ** MythLogBot **
[21:51:43] peper03: stichnot: I think there is some kind of support directly in libdvdnav for cutlists but not in the Myth sense. You can create a 'map' file of swearing/violence/whatever and it will skip those bits automatically during playback. Probably nothing we need to worry about though.
[21:52:06] stichnot: wow, cool.
[21:52:21] danielk22: stichnot: That is true. They are close enough for it not to matter most of the time.
[21:52:53] stuartm: peper03: this should be simple to fix, I'll take a stab at it tomorrow
[21:53:33] dmfrey (dmfrey! has quit (Quit: Ex-Chat)
[21:54:16] stichnot: My concern with cutlists is to make it appear seamless, e.g. a 1-hour recording with 10 minutes of cut regions will appear as a 50-minute recording with no discontinuities in time display or seeking.
[21:54:35] peper03: stichnot, danielk22: I've certainly noticed that problem with keyframes. I have wrote a script to trim the start and end of recordings and filter any data streams from recordings. If I mark the start and end of commercials before trimming, they're nearly always one or two keyframes off afterwards.
[21:54:42] stichnot: I doubt libdvdnav has that concern. :)
[21:54:52] Steve-Goodey (Steve-Goodey! has quit (Read error: Connection reset by peer)
[21:55:27] Jordack (Jordack! has quit ()
[21:55:30] stuartm: the best guess track reselection code is potentially bogus for DVD as it assumes the first track matching the target language is the one we want, that doesn't account for a commentary track preceding the main audio
[21:55:48] peper03: stichnot: I doubt it too. I've not tried the map file thing. I just noticed the message every time I tried to play a DVD that the map file couldn't be found.
[21:56:49] stuartm: again this has got me wondering whether there are hints provided by the VM about which track we want to use, so I'll look into that as well
[21:57:07] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[21:57:32] peper03: stuartm: At least with this DVD, the commentary track *doesn't* come before the main audio. I definitely had problems due to sorting. When I commented out the 'sort' line, it worked ok (at least until I went through and selected each audio track – at some point the streams must have been resorted somewhere else).
[21:58:06] jya: stichnot: back… #10622 ce guy stated that the issue started after he upgraded to 0.26 from 0.25. I chased that bug the whole day yesterday…
[21:58:06] ** MythLogBot **
[21:58:57] jya: I have another issue that was introduced with 0.26. I thought they were related; but they aren't… so I chased a non-existing problem (by that I mean, the issue is in ffmpeg itself) with your ticket.
[22:00:50] peper03: stuartm: Regarding the hints, I don't think the VM cares about anything like that. As far as I know, it just knows which track it's been told to play.
[22:02:41] SteveGoodey (SteveGoodey! has joined #mythtv
[22:05:08] stichnot: jya: the 10622 reporter says "Since upgrading to .25, ..." and I'm pretty sure I verified that clip under 0.25, so I assumed it was a regression in the ffmpeg version we used in 0.25 and the regression wasn't fixed in subsequent versions
[22:05:30] jya: ah ok… "since"
[22:05:35] stichnot: "I verified that clip" = "I verified the clip caused problems"
[22:05:49] jya: I think one of the core issue here, is that the length is stored in the database.
[22:06:11] jya: so if it was improperly calculated at some stage, no fix is going to be immediately available
[22:06:23] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 260 seconds)
[22:06:35] jya: unless you have a DB format upgrade, where can can force to recalculate the length
[22:06:46] jya: I misread the post
[22:06:50] stichnot: If I run "mythcommflag --rebuild" on it, I'm pretty sure the length looks right
[22:07:07] stichnot: so I've been testing without any markup in the DB
[22:07:36] jya: as soon as you play the file with avfd, it stores the length in the DB
[22:07:49] peper03: stuartm: I've managed to make some changes that, so far, is making Myth play any DVD I've thrown at it (except for things like the audio track problem). It seems there's a lot of caching being done by different components. The changes can't be commited as I have them because they would probably affect other media or maybe other tools.
[22:08:01] stichnot: A number of people have reported that "analog recordings" stopped showing the correct length as of 0.25, until they run mythcommflag --rebuild across the whole library
[22:08:20] peper03: stuartm: Do you want to look at them by email to see if you see any problems in the direction I've gone?
[22:08:20] jya: does it really take that long to calculate the length ? i'm not sure there was much to gain in storing the length anywhere, at least for use during playback other than headaches
[22:09:36] stichnot: I don't remember why we started tracking the length, perhaps it was related to the discussion between me, taylorr, and danielk22 about displaying accurate duration and position
[22:11:24] stuartm: peper03: a ticket might be better, that way others maintaining the general playback code can comment and in the event that I'm suddenly too busy to take a look, there's a record of your work that another dev can pick up on
[22:11:54] jya: tu get the media length displaying anything other than 400+ hours, I had to prevent searching in the DB for the duration, and revert danielk22 change about a call to av_estimate_timings being redundant
[22:12:19] jya: av_estimate_timings wasn't redundant at all.. while it may speed up startup, that itself broke timing calculation for some video
[22:12:37] stichnot: why is it wrong to take the duration from the DB?
[22:13:07] stichnot: i.e., who was writing it wildly incorrectly into the DB?
[22:13:18] jya: what Captain_Murdoch re-added to call av_estimate_timings for some media, doesnt awlays work, and not for your colvert sample
[22:13:24] jya: oh it's not that it's wrong..
[22:13:49] jya: is that with the removal of av_estimate_timings that danielk22 did. that broke the length calculation to start with.
[22:13:56] danielk22: jya: I remember tracing the code and seeing that av_estimate_timings had already been called implicitly by ffmpeg for the recordings I looked at. Must have been some container I didn't test that didn't call it.. Do you recall anything about the files that had that problem?
[22:13:59] jya: so what was stored in the DB was likely incorrect
[22:14:14] stuartm: honestly a lot of my email doesn't get the attention it deserves, I mean to take a look but something else is always more important and ultimately it just sits in my inbox for days or weeks and in the worst cases years
[22:14:24] jya: danielk22: I was only playing with that colbert file
[22:14:38] jya: even after I removed all myth mpegts code, I was still getting 400+ hours
[22:14:53] jya: then I realised the length came from the DB, which was incorrect from an earlier reading
[22:15:02] danielk22: stuartm: I have 8 month old e-mails in my inbox with MythCenter-wide fixes :|
[22:15:37] jya: so I removed the loading of the duration from the DB, and still had 400+ hours. So I re-added the call to av_estimate_timings, and bang: you got a different length (still incorrect, but identical to what mplayer shows)
[22:16:56] stichnot: jya: are you saying that mythfrontend is updating the length in the DB? I assumed only mythbackend/mythcommflag/mythtranscode would do that.
[22:17:26] jya: stichnot: yes.. as soon as avformatdecoder read the file, if there' nothing in the DB, it adds it
[22:17:35] peper03: stuartm: Ok, I can create a ticket too. Looking at my changes and mentally stripping out the debug stuff I've added that's not necessary, it actually only comes down to a small change in DVDRingBuffer and a few changes in AVFormatDecoder. It's the AVFormatDecoder stuff that actually needs a bit of consideration so presumably danielk22 would be a better reviewer/hint giver.
[22:20:44] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[22:23:36] danielk22: jya: Can you take a look at these warnings? . . . s%20%2819%29
[22:23:39] stichnot: jya: I don't think mythfrontend should be modifying the length in the DB at all
[22:25:21] jya: the way I read avfd, it calls PlayBackInfo::QueryTotalDuration();
[22:25:25] jya: which does a DB access
[22:26:35] danielk22: stichnot: jya: I may be responsible for the DB update, I don't recall. Even so I don't think AVFD should be doing one..
[22:29:08] jya: danielk22: no, that was Beirdo change 53663999
[22:29:26] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[22:30:15] MythBuild: build #3248 of master-freebsd-64bit is complete: Failure [4failed compile core] Build details are at . . . /builds/3248 blamelist: Daniel Thor Kristjansson < >
[22:30:48] jya:
[22:31:23] jya: hum… it may not be storing it afterall
[22:31:32] jya: need to check what SetFileLength does
[22:31:38] jya: gdb to the rescue
[22:31:59] MythBuild: build #4415 of master-linux-64bit is complete: Failure [4failed compile core] Build details are at . . . /builds/4415 blamelist: Daniel Thor Kristjansson < >
[22:32:31] MythBuild: build #234 of master-f17–32bit is complete: Failure [4failed compile core] Build details are at . . . t/builds/234 blamelist: Daniel Thor Kristjansson < >
[22:33:08] MythBuild: build #15 of master-linux-64bit-clang is complete: Failure [4failed compile core] Build details are at . . . ng/builds/15 blamelist: Daniel Thor Kristjansson < >
[22:33:16] MythBuild: build #150 of master-debian-wheezy-64bit is complete: Failure [4failed compile core] Build details are at . . . t/builds/150 blamelist: Daniel Thor Kristjansson < >
[22:33:20] danielk22: bah, I gotta run. But I'll fix the build as soon as I get back..
[22:33:26] danielk22: about an 1hr
[22:37:19] MythBuild: build #437 of master-linux-64bit-icc is complete: Failure [4failed compile core] Build details are at . . . c/builds/437 blamelist: Daniel Thor Kristjansson < >
[22:38:57] Sharky-Sleep is now known as Sharky112065
[22:45:19] Sharky112065 (Sharky112065! has quit (Quit: “The only way to have a friend is to be one.” ― Ralph Waldo Emerson)
[22:52:21] gigem: Live TV question time. Bear with me a little first.
[22:52:23] gigem: When scheduling around live TV, there are four cases when another showing is possible: 1) equivalent input at the same time, 2) equivalent input at a later time, 3) nonequivalent input at the same time and 4) nonequivalent input at a later time. Input equivalency is determined by priority differences being less than the preferred input priority setting. If case 1 is possible, the current code automatically
[22:52:25] gigem: and silently chooses it. If cases 2 is possible, the current code includes a "record later" option in the live TV popup. Note there is no guarantee a later showing will actually be recorded, but it probably will if nothing else changes.
[22:52:27] gigem: In the scheduler settings cleanup, I'm removing the use of the preferred input priority in the equivalent input cases for live TV. Cases 1 and 2 will now be distinguished from cases 3 and 4 by straight priority comparisons.
[22:52:29] gigem: Okay, now for the question. Should there be any other changes to live TV scheduling? Without giving it a huge amount of thought, I think the two other options are to a) automatically choose case 2 (after case 1) when possible or b) automatically choose cse 1, 2, 3 or 4 (in that order) when possible.
[22:55:39] gigem: Oops. I missed one thing. It looks like the current code lumps cases 2 and 4 together when offering the "record later" option.
[22:58:48] natanojl (natanojl! has joined #mythtv
[23:18:37] Sharky-Sleep (Sharky-Sleep! has joined #mythtv
[23:18:50] Sharky-Sleep is now known as Sharky112065
[23:22:49] dblain (dblain!~dblain@mythtv/developer/dblain) has quit ()
[23:23:18] stichnot: gigem: are you suggesting any changes to the popup dialog?
[23:27:42] gigem: stichnot: I keep flopping back and forth between the status quo and handling all options automatically.
[23:28:20] natanojl (natanojl! has quit (Ping timeout: 250 seconds)
[23:31:36] stichnot: gigem: I think there should be a popup for cases 2/3/4. We can't know whether the person fell asleep during Live TV and will be very upset to miss a recording, or if the current Live TV more important than a scheduled recording.
[23:42:58] gigem: stichnot: Noted. FYI, they way things work, it's not currently possible to let the user choose option 3. It has to either be handled automatically or not at all.
[23:52:01] stichnot: gigem: that makes sense.
[23:54:11] dblain (dblain!~dblain@mythtv/developer/dblain) has joined #mythtv
[23:56:47] jya: gigem: what exactly are you trying to fix with that change ? or maybe more accurately, what is currently broken?
[23:58:34] jya: to me what I would expect things to do is: if the user is watching live TV, and there's a recording about to happen. If it can record on another recorder, then it does it automatically. Otherwise prompt the user to "siwtch liveTV to the show to be recorded" or "cancel recording"
[23:59:13] zombor (zombor!~zombor__@ has joined #mythtv
[23:59:14] zombor (zombor!~zombor__@ has quit (Changing host)
[23:59:14] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[23:59:54] jya: everything else is already too complicated. the record later option, while nice, how likely is it going to happen, especially as there's no guarantee it will actually work later. And the user can always exit that current plyback by changing channels (if possible, or using another multiplex)

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