:: #mythtv

Daily chat history

Current users (83):

alan`, aloril, amessina, Anssi, anykey_, Beirdo, Captain_Murdoch, cesman, Chutt_, clever, Cougar, danielk221, dblain, dekarl, ElmerFudd, fetzerch, foobum, ghoti, Gibby, gigem, gregL, GreyFoxx, HeXiLeD, IReboot, J-e-f-f-A, jams, jarle, jarryd, jhall_, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, jya_, kc, Kevin`, knightr, kurre2, kwmonroe, laga, mick0_, monkeypet69, mrand, MythBuild, MythLogBot, nephyrin, neufeld, Peitolm, peper03, Peps, petefunk, poptix, purserj, rhpot1991, rsiebert_, Seeker`, seld, Sharky112065, skd5aner, sl1ce, SmallR2002, sphery, sraue, SteveC, stuarta, stuartm, superm1, taylorr, tgm4883, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang1, XDS2010, xris, _charly_
Saturday, March 2nd, 2013, 00:04 UTC
[00:04:54] natanojl (natanojl! has quit (Ping timeout: 244 seconds)
[00:29:36] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 272 seconds)
[00:33:38] stichnot (stichnot!~stichnot@ has joined #mythtv
[00:33:38] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[00:33:38] stichnot (stichnot!~stichnot@ has quit (Changing host)
[00:41:58] danielk221: I'm testing a fix to some SIGNAL/SLOT breakage + ABI version bump for the Qt5 patchset.
[00:42:44] jpabq: stichnot: I wonder why the left/top cropping values are ignored?
[00:45:02] clever (clever!~clever@ has quit (Ping timeout: 245 seconds)
[01:00:26] clever (clever!~clever@ has joined #mythtv
[01:02:09] stichnot: jpabq: I would guess that handling them would be "hard", and nonzero values are not seen in the field?
[01:08:36] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[01:20:00] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[01:20:37] Seeker`: danielk221: is master currently not usable then?
[01:22:51] danielk221: I'd wait a couple hours.
[01:23:00] clever (clever!~clever@ has quit (Ping timeout: 248 seconds)
[01:23:13] clever (clever!~clever@ has joined #mythtv
[01:24:13] danielk221: ad8605c6d3847604 is the problem, you can revert that locally until I get the real fix in.
[01:39:41] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[01:44:28] Seeker`: hmm, think I was right about 5cced61dd causing playback problems with C4 HD stuff. Even after rebuilding the seektable
[02:39:18] danielk221 (danielk221!~danielk@ has quit (Quit: Leaving.)
[02:39:20] danielk222 (danielk222!~danielk@ has joined #mythtv
[02:42:58] wagnerrp: seems the database table is crashed...
[02:43:08] wagnerrp: wiki database tables
[02:45:48] danielk222: Seeker`: FYI I've pushed the fix.
[02:45:57] Seeker`: danielk222: thanks
[02:48:25] wagnerrp: what's that database checking perl script that is its own polish domain?
[02:53:55] Seeker`:
[02:54:14] wagnerrp: ah, thanks
[02:54:24] wagnerrp: i was thinking
[02:55:04] Seeker`: hmm. I'm not sure its a good idea to try to update tickets at 0300
[02:55:17] Seeker`: I have no idea if what I've written makes sense :P
[02:57:18] wagnerrp: the system has been up for just under 3 hours
[02:57:27] wagnerrp: mysql reports it has been running for 8 hours
[02:57:28] wagnerrp: huh?
[02:58:10] Seeker`: that sounds wrong
[02:58:12] danielk222: 8 CPU hours maybe? there are multiple CPUs.. Is it really busy?
[02:58:25] Seeker`: has the clock been changed since startup?
[02:58:49] Seeker`: are you travelling close to the speed of light?
[02:59:01] wagnerrp: maybe NTP kicked in shortly after the mysql server started
[02:59:04] danielk222: wagnerrp: it has been up more than 3 hours.. it is 10pm here and it was up at 5pm local time..
[02:59:06] wagnerrp: this is alcor by the way
[02:59:18] wagnerrp: [rwagner@alcor ~]$ uptime
[02:59:18] wagnerrp: 02:57:06 up
[02:59:32] Seeker`: thats the time
[02:59:39] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[02:59:45] Seeker`: look at the bit of text after that
[02:59:52] wagnerrp: oh, 8:05
[02:59:58] wagnerrp: nevermind
[03:01:35] Seeker`: I guess alcor is in the UK
[03:01:44] wagnerrp: no, just using UTC
[03:01:54] wagnerrp: its at OSUOSL
[03:01:55] Seeker`: fair enough
[03:02:25] wagnerrp: oregon state runs a data center for open source projects
[03:17:45] wagnerrp: how much hardware swapping effort are the OSUOSL, or would they want one of the washington folks to drive down and do an upgrade?
[03:17:58] wagnerrp: *folks willing to do
[03:20:19] wagnerrp: just wondering how difficult an upgrade would be, if we found the hardware to be faulty
[03:33:52] peper03 (peper03! has quit (Read error: Operation timed out)
[03:36:05] peper03 (peper03! has joined #mythtv
[03:44:11] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[03:45:04] stichnot: Seeker`: can you give me the seektable before and after mythcommflag --rebuild for an affected recording?
[03:45:34] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Remote host closed the connection)
[03:46:03] wagnerrp (wagnerrp!~wagnerrp_@ has joined #mythtv
[03:46:04] wagnerrp (wagnerrp!~wagnerrp_@ has quit (Changing host)
[03:46:04] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[04:40:24] SteveC (SteveC! has joined #mythtv
[04:42:48] SteveC_ (SteveC_! has quit (Ping timeout: 264 seconds)
[04:44:49] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 248 seconds)
[04:46:10] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[06:00:04] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[06:17:39] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds)
[06:22:01] Sharky112065 is now known as Sharky-Sleep
[06:31:01] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[06:37:50] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 260 seconds)
[07:35:22] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[07:39:34] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Ping timeout: 244 seconds)
[07:44:16] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[07:58:43] dekarl (dekarl! has quit (Ping timeout: 256 seconds)
[07:59:23] dekarl (dekarl! has joined #mythtv
[08:10:36] SteveGoodey (SteveGoodey! has joined #mythtv
[08:37:25] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:50:25] Tobbe5178 (Tobbe5178! has joined #mythtv
[09:31:06] coling (coling! has quit (Ping timeout: 272 seconds)
[09:47:20] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[09:53:56] Seeker`: stichnot: did you see ?
[10:02:14] stoffel (stoffel! has joined #mythtv
[10:08:41] SteveGoodey (SteveGoodey! has joined #mythtv
[10:21:19] Seeker`: stichnot: also, how do I get a seektable?
[10:41:58] Wolfgang2 (Wolfgang2! has joined #mythtv
[11:25:29] stoffel (stoffel! has quit (Remote host closed the connection)
[11:37:16] natanojl (natanojl! has joined #mythtv
[11:43:50] aloril (aloril! has quit (Ping timeout: 256 seconds)
[11:57:46] aloril (aloril! has joined #mythtv
[12:11:18] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[13:18:44] ElmerFudd (ElmerFudd! has quit (Ping timeout: 248 seconds)
[13:21:16] peper03: I added my updated patch to #11371 last night and a sample image to the repository.
[13:21:16] ** MythLogBot **
[13:25:08] peper03: Regarding the next steps I'd like to take: I need some way of passing the NAV packets through to AvFormatDecoderDVD. I've submitted a patch to ffmpeg, which would allow those packets through. I have no idea though at the moment whether it will be accepted. After several responses and a tweaked patch, I've had no response for several days. so I don't know whether it's still even under consideration.
[13:26:38] peper03: For the case that they reject the patch (I think if there's a sticking point, it's that they can't see why it's necessary), what is the feeling here of applying it to Myth's copy?
[13:27:16] ElmerFudd (ElmerFudd! has joined #mythtv
[13:28:05] peper03: I'd rather have it upstream but I've been asked whether there is code that already uses it. There isn't yet, since I don't want to spend a lot of time and effort implementing something that relies on that patch, only for it to be rejected anyway.
[13:28:30] peper03: The patch for ffmpeg is here:
[13:29:15] peper03: A couple of tweaks are necessary for Myth, but nothing major.
[13:32:39] IReboot (IReboot! has quit (Remote host closed the connection)
[13:38:21] Tobbe5178 (Tobbe5178! has quit (Read error: Connection reset by peer)
[13:53:21] Steve-Goodey (Steve-Goodey! has joined #mythtv
[13:54:01] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[14:32:33] SteveGoodey (SteveGoodey! has joined #mythtv
[14:42:18] Wolfgang2 (Wolfgang2! has quit (Quit: Wolfgang2)
[14:52:06] Sharky-Sleep is now known as Sharky112065
[14:53:15] stichnot: Seeker`: yes I saw the ticket. To get the seektable for a given recording, find the chanid and starttime and run the mysql query "select * from recordedseek where chanid=... and starttime=... order by mark, type;"
[14:59:02] stichnot: Seeker`: for seektable entries where type=33, the offset column should be the timestamp in milliseconds for the frame number in the mark column.
[14:59:58] stichnot: Seeker`: frame rate is calculated as frames per second, whereas frame duration is seconds per frame, hence the inverse calculcation.
[15:13:53] Seeker`: stichnot: don't dur and den still mean the same thing though?
[15:13:55] IReboot (IReboot! has joined #mythtv
[15:15:22] Seeker`: sorry, num and den
[15:27:43] Seeker`: ah, nevermind
[15:29:51] stichnot: Seeker`: the code is separated into the player side, which directly accumulates the duration using AVRational, and the recorder size, which tracks "ticks" and when needed uses FrameRate to convert to duration. I would have liked to use AVRational similarly in the recorder, but we have a policy of not using ffmpeg libraries in the backend to avoid ffmpeg-related crashes.
[15:32:13] Seeker`: I'll try to get that seektable stuff if about 20 mins
[15:33:10] stichnot: Thanks.
[15:35:55] petefunk (petefunk!pfunk@unaffiliated/petefunk) has quit (Ping timeout: 252 seconds)
[15:36:19] petefunk (petefunk!pfunk@unaffiliated/petefunk) has joined #mythtv
[15:44:56] Seeker`: stichnot: pre-rebuild is
[15:49:19] Seeker`: after
[15:53:09] tonsofpcs: wagnerrp: where is this data center?
[16:12:56] neufeld (neufeld! has quit (Remote host closed the connection)
[16:12:58] stichnot: Seeker`: my guess is that the first 25 frames of the recording are somehow corrupted, as the mythcommflag player seems to be ignoring them. The type=9 file offsets seem to match up if you subtract 25 from recorder's mark values.
[16:13:46] Seeker`: why does it work ok without your patch then?
[16:14:00] Seeker`: its like that for 90% of my channel 4 HD recordings
[16:14:20] stichnot: Seeker`: what happens if you set a bookmark somewhere past the 1 second mark, exit playback, and restart playback at the bookmark?
[16:15:50] stichnot: I have no idea why normal playback without seeking would depend in any way on the duration values in the seektable, which is the only thing that commit should be affecting
[16:16:42] stichnot: Two other things worth trying:
[16:17:09] neufeld (neufeld! has joined #mythtv
[16:17:53] stichnot: 1. Remove the duration seektable entries for that recording – "delete from recordedseek where chanid=... and starttime=... and type=33;"
[16:18:28] stichnot: 2. Show me the seektable after reverting the commit and re-running mythcommflag --rebuild
[16:18:34] neufeld (neufeld! has quit (Remote host closed the connection)
[16:19:37] stichnot: Seeker`: your observation about video frame buffering seems consistent with corruption, though again I don't know how that commit would have affected things
[16:24:40] stichnot: Seeker`: the thing that would probably help most is if you could provide the first ~50MB of that recording for me to look at
[16:28:20] Seeker`: stichnot: tried 1 min in to the recording, still stutters
[16:28:28] Seeker`: tried skipping 10 mins and it plays normally
[16:29:38] Seeker`: hmm, I should probably point out it is only the frontend which I am adding / removing your patch. The backend is past that already. I'm not sure how rebuilding the seek table on the back end changes things based on whether the frontend has the patch or not
[16:30:10] Seeker`: and how would you suggest I get the first 50MB?
[16:32:33] tonsofpcs: are I-frames roughly 25 frames apart?
[16:38:43] stichnot: Seeker`: the patch affects mythbackend only in the seektable creation during recording. It affects mythcommflag --rebuild. It is really not supposed to affect mythfrontend except with respect to the slightly different values that might be put into the seektable.
[16:40:05] stichnot: Seeker`: dd if=/path/to/recording.mpg of=/tmp/test.mpg bs=1024k count=50
[16:43:39] Seeker`: stichnot:
[16:44:20] Seeker`: it does look like there is something odd at the beginning / halfway through
[16:45:45] Seeker`: ah, ingnore the 'halfway through' comment
[16:45:51] Seeker`: but the start does look a bit weird
[16:46:31] Seeker`: the patch must be doing something with the frontend, as removing it wouldn't make the recordings work again if it didn't
[16:47:59] stichnot: yeah, I would assume that too, but I just can't imagine why. Hopefully the sample will sort things out
[17:11:52] stichnot: Seeker`: I just noticed that my own HD-PVR recordings are having playback problems like this, and reverting that commit seems to fix it :(
[17:12:11] Seeker`: good to know it isn't just me being crazy :P
[17:13:18] Seeker`: I would guess it is one of the * 1000 or /1000 in avformatdecoder.cpp or decoderbase.*, or H264Parser
[17:13:32] Seeker`: but I can't be sure because I don't understand how the code works
[17:42:47] Seeker`: stichnot: is the first change in avformatdecoder.cpp correct? Everywhere else there seems to have been a change by a factor of 1000 (i.e. added or removed either a * or / by 1000) but for that first change you've got it altered by a factor of 1,000,000 (removed a / 1000 and added a * 1000)
[17:48:02] wagnerrp: tonsofpcs: it's OSUOSL
[18:37:23] tonsofpcs: wagnerrp: right, where is it? Portland?
[18:43:15] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds)
[19:07:56] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[19:12:20] stichnot: Seeker`: originally the code had a mishmash of units – seconds, milliseconds, microseconds. I changed it to track seconds internally, and write milliseconds to the DB as before.
[19:12:53] stichnot: anyway, it's going to be a few hours until I can look into it, but at least I can reproduce some sort of problem.
[19:16:06] jhall_ (jhall_!~jhall@2001:468:d01:9c:226:b9ff:fe2d:482e) has quit (Remote host closed the connection)
[19:19:15] Seeker`: stichnot: not particularly desperate for a fix right now as I can get on fine just cutting out that patch. Let me know if you need anything tested.
[19:23:32] wagnerrp: specifically? i'm not sure, oregon state university (OSU) runs it
[19:30:27] jhall_ (jhall_!~jhall@2001:468:d01:9c:226:b9ff:fe2d:482e) has joined #mythtv
[19:32:35] neufeld (neufeld! has joined #mythtv
[19:56:00] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[20:59:06] ElmerFudd (ElmerFudd! has quit (Remote host closed the connection)
[21:01:11] rsiebert_ (rsiebert_! has joined #mythtv
[21:01:11] rsiebert (rsiebert! has quit (Read error: Connection reset by peer)
[21:03:01] stichnot: Seeker`: you can try this:
[21:05:43] stichnot: looks like I changed the meaning of H264Parser::frameRate() to be seconds instead of milliseconds, but left in the scaling factor
[21:07:44] stichnot: for some reason I thought that function wasn't being called any more after I added getFrameRate()
[21:10:17] Seeker`: stichnot: yup, seems to fix it here
[21:11:26] stichnot: great, thanks for testing.
[21:11:49] stichnot: I'm pulling in the Qt changes and building so that I can commit this
[21:17:50] stichnot: Seeker`: thanks for your help on this.
[21:18:03] Seeker`: stichnot: no problem, thanks for fixing it :)
[21:29:43] ElmerFudd (ElmerFudd! has joined #mythtv
[22:08:36] bergqvistjl (bergqvistjl! has joined #mythtv
[22:10:24] bergqvistjl: This may be more appropriate to the devs. Can the frontend player detect and respond appropriately to changes in the video scan (from Progressive to Interlaced and vice-versa in UK Freeview HD video) mid-playback? Because a lot of the time when i watch a program that's interlaced, which then finishes and moves onto another program that's progressive, the player is de-interlacing the progressive video, and slow the quality is sli
[22:11:31] bergqvistjl: I think it may only be responding correctly to changes in the encoding mid-playback some of the time, but I can't be sure.
[22:11:58] bergqvistjl: I think it handles going from progressive to interlaced better, than going from interlaced to progressive.
[22:21:48] bergqvistjl (bergqvistjl! has left #mythtv ()
[22:42:12] joki (joki! has quit (Ping timeout: 264 seconds)
[22:42:13] joki- (joki-! has joined #mythtv
[22:42:24] joki- is now known as joki
[22:43:56] aloril (aloril! has quit (Ping timeout: 276 seconds)
[22:45:00] danielk222 (danielk222!~danielk@ has quit (Quit: Leaving.)
[22:51:18] Steve-Goodey (Steve-Goodey! has quit (Quit: Konversation terminated!)
[22:56:08] aloril (aloril! has joined #mythtv
[23:11:46] danielk221 (danielk221!~danielk@ has joined #mythtv
[23:25:16] wagnerrp: bergqvistjl: yes, mythtv can handle such thngs
[23:29:09] mick0_ (mick0_!~user@unaffiliated/mick0) has joined #mythtv
[23:57:08] natanojl (natanojl! has quit (Ping timeout: 248 seconds)

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