:: #mythtv

Daily chat history

Current users (86):

aloril, Anssi, anykey_, Beirdo, brfransen, bsilvereagle, CaCtus491, Captain_Murdoch, cesman, clever, coling, Cougar, danielk22, dblain, dekarl, ElmerFudd, f33dMB, fetzerch, foobum, foxbuntu`, ghoti, gregL, GreyFoxx, Guest48558, IReboot, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jwhite, jya, kc, kenni, Kevin`, kormoc, kurre2, kwmonroe, laga, MaverickTech, monkeypet, mrand, MythBuild, MythLogBot, neufeld_AFK, NightMonkey, Peitolm, Peps, petefunk, pheld, poptix, purserj, rhpot1991, rsiebert_, Seeker`, seld_, Sharky-AFK, skd5aner, sl1ce, SmallR2002, sphery, sraue, stuarta, stuartm, superm1, sutula, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, Vernon_at_work_, wagnerrp, wahrhaft, wolfgang1, xavierh_, XDS2010, xris, _charly_
Tuesday, December 18th, 2012, 00:00 UTC
[00:00:12] jya: I reckon to do the sync with ffmpeg/stable (knowing I had done the biggest task of updating our own code earlier) took me 4 hours. 3 of each was just for configure
[00:00:59] jya: I've tried to reformat configure this time so a future patch will apply more easily. moving the myth part elsewhere, keeping most of the ffmpeg original code separated.
[00:02:44] taylorr: jya: I think that we used to have custom code in aviobuf.c in 0.25-fixes and that it got removed with the sync for 0.26
[00:03:03] jya: let me check...
[00:03:50] jya: i have kept all the diff between our version and ffmpeg at the time of the sync
[00:04:19] jya: these days, most of the update to ffmpeg will apply cleanly to our copy due to how I've made our changes to ffmpeg…
[00:04:41] jya: what take the longest is changing our own code following the change of API or the change of behaviour...
[00:04:59] jya: like the new use of planar data instead of interleaved
[00:05:23] jya: the code I had written for the 0.26 sync, suddenly didn't work. no idea why
[00:06:39] taylorr: jya: yep, definitely some custom change that didn't get carried to the next sync
[00:06:45] taylorr: not sure if it's important
[00:06:50] jya: i'll have a look
[00:07:21] jya: i'm fairly certain that with the method I'm using, no changes can get lost
[00:07:42] jya: because I work using patches between the different ffmpeg revision, and apply them manually to our code.
[00:08:37] jya: though Beirdo used a more heavy handed method in his resync in Feb. He copied the entire ffmpeg code, then re-applied our own change… though I think it was a necessary step to reset the sync to start from a good base
[00:09:48] taylorr: jya: here is the change for 0.25 ->
[00:10:15] taylorr: does the latest sync and current release/1.0 have any differences for aviobuf.c?
[00:10:19] jya: hum… interesting
[00:10:35] jya: it's precisely something that could cause my grief with seeks on SG
[00:10:49] jya: aviobuf.c is not in the list of files modified
[00:11:14] Sharky-Sleep is now known as Sharky112065
[00:11:19] jya: that change makes sense. it doesn't do a seek if we know we are likely to have it in the ringbuffer
[00:11:54] jya: having said that, nothing guarantee that the value used (16384) is in sync with how the ring buffer buffers things
[00:12:26] taylorr: jya: fyi, it's no longer called url_seek... they changed the naming convention to avio_seek
[00:12:37] jya: that thing isn't thread safe though
[00:13:11] taylorr: danielk22: ^^^ any idea about the above?
[00:14:50] taylorr: jya: if it's just an optimization then I'm going to move forward
[00:15:08] jya: i'll see if it helps with my AVI playback issue
[00:15:14] jya: could very well be
[00:15:42] taylorr: jya: the results should be interesting
[00:22:25] stichnot: danielk22: Why do we have ProgramInfo::positionMapDBReplacement? The only place it is set is in SetPositionMapDBReplacement() which is never called.
[00:34:46] danielk22: stichnot: It was added to support running mythcommflag on files without a DB. If you checkout fixes/0.24 the call is still there to use it.
[00:36:09] danielk22: I don't know why it isn't being used anymore, maybe that is a bug or perhaps some new mechanism was devised and the old code was left in there as well.
[00:38:22] stichnot: danielk22: thanks.
[00:44:08] danielk22: taylorr: I don't see any way that patch in would cause any problems with the RingBuffer. It won't have any performance benefit since we already do a similar optimization, but it won't hurt.
[00:44:42] taylorr: danielk22: so is it an old optimization that is no longer needed?
[00:44:58] danielk22: Is it ours?
[00:45:02] jya: taylorr: yes… the change to aviobuf got lost with Beirdo resync in April.. He removed the whole ffmpeg content then, then copied the original ffmpeg, then applied all past patches (which wasn't including the aviobuf.c change)
[00:45:24] taylorr: danielk22: AFAICT, it's ours
[00:45:42] danielk22: In that case I think this can get lost on the cutting room floor. :)
[00:46:36] zombor (zombor!~zombor__@ has joined #mythtv
[00:46:36] zombor (zombor!~zombor__@ has quit (Changing host)
[00:46:36] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[00:47:28] danielk22: We do this optimization Ringbuffer itself, I believe since 0.25. The one in RingBuffer is much better since it knows exactly how much we've already buffered.
[00:47:43] jya: taylorr: with your diff, can you give a tad more context? it's useless as is
[00:47:47] jya: diff -Nau
[00:48:44] Sharky112065 is now known as Sharky-AFK
[00:49:25] taylorr: jya: I already blew that code away... you'll have to look at 0.25-fixes to determine what the specifics are
[00:49:43] jya: never mind, I can get back to that info anyway
[00:49:56] jya: i first need to find out the history of that patch
[00:50:08] taylorr: I'm guessing that is't the function avio_fseek or avio_seek
[00:50:21] taylorr: err, it's in
[00:51:54] jya: it's url_fskip / avio_fskip
[00:52:22] jya: . . . b1fe2c3aeea4
[00:52:40] jya: Isaac change, 7 years ago
[01:04:33] Mousey (Mousey! has quit (Quit: Read Error: Connection reset by beer)
[01:07:04] taylorr: some of these mpegts.c changes need to get pushed upstream... what a nightmare
[01:16:27] jya: taylorr: the mpegts code is completely separate now.
[01:17:06] jya: we don't use ffmpeg one anymore… i had a look on how we could sync that so it works on top of ffmpeg current one
[01:17:09] jya: i quickly gave up
[02:00:18] tonsofpcs: gah!
[02:00:30] tonsofpcs: I stopped the logging backend and rebooted the system and it did it again (#11027)
[02:00:30] ** MythLogBot **
[02:01:11] tonsofpcs: err, sorry, wrong #
[02:01:51] tonsofpcs: #11207
[02:01:51] ** MythLogBot **
[02:02:29] jya: taylorr: this change to avio_skip is not relevant during playback.. seems to only be used at the beginning, when it parses the header
[02:03:30] tonsofpcs: but I may have figured out the trigger condition that I was missing last time I tried
[02:03:45] tonsofpcs: I think the show being watched when this happens may need to be one that is recording as well.
[02:04:15] taylorr: jya: ok, cool... by any chance do you know where functions like "ff_sine_1024" are linked?
[02:04:38] jya: what do you mean?
[02:05:02] taylorr: I'm getting this "../../external/FFmpeg/libavcodec/ undefined reference to `ff_sine_1024'"
[02:05:42] jya: did you do a make distclean ?
[02:07:02] taylorr: yep, I'm taking 0.25-fixes and incrementally updating ffmpeg one month at a time... this popped up on me when compiling mythfrontend
[02:07:46] jya: i wouldn't do it that way
[02:08:08] jya: 0.25-fixes way of having files of the same name with completely different content
[02:08:09] taylorr: trying to find out where something broke
[02:08:15] jya: make the follow up very difficult
[02:08:43] jya: instead I would start from 0.26, and apply the revert patch
[02:08:57] jya: because that would apply much more easily than the other way round
[02:09:08] taylorr: I guess that's a possbility too
[02:09:33] jya: what I did to track done the AVI bug, I made a patch that reset many of the myth optimisation and crash fix (like testing a pointer is non null before using it)
[02:09:44] jya: because those changes only improve stability, not the feature set
[02:10:06] jya: then after applying that patch, that pretty much reset ffmpeg in mythtv to be very similar to ffmpeg's one
[02:10:21] jya: i applied the diff obtained from the ffmpeg bisect
[02:11:21] jya: I knew the error occurred between 0.25 and 0.26
[02:11:33] taylorr: jya: do you have a patch against 0.26-fixes that gives me a clean start against a certain ffmpeg hash?
[02:11:47] jya: so I started a git bisect in the ffmpeg tree between the two hash used on 0.25 and 0.26
[02:11:59] jya: in another window, in mythtv code I do:
[02:12:04] jya: cd ~/Work/mythtv/git/mythtv/; rm -rf external/FFmpeg ; git reset --hard HEAD ; patch -p2 < default.diff ; cd external/FFmpeg/
[02:12:57] jya: that I applied the diff generated from ffmpeg with git diff hash_used_in_026 HEAD
[02:13:06] jya: and I do patch -p1 < that_patch.diff
[02:13:17] jya: fix the various errors popping here and there
[02:14:05] jya:
[02:14:57] jya: this one reset to almost stock ffmpeg hash f218121
[02:15:03] jya: (the one used in 0.26)
[02:16:00] jya: so in ffmpeg, if you use git bisect, you do:
[02:17:01] jya: actually, sorry that patch reset to ffmpeg ea5dab58
[02:17:27] jya: so I have two windows, one in mythtv code, one is ffmpeg
[02:17:39] jya: in ffmpeg, after the git bisect good/bad ; you do:
[02:17:41] jya: git diff ea5dab58e074a91330e1f076a4cbe8fece889afe HEAD > `git describe`.diff && git describe
[02:18:19] jya: if you find that git describe returns an error (because it's in the middle of a merge) and can't give you something , do git bisect skip and redo : git diff ea5dab58e074a91330e1f076a4cbe8fece889afe HEAD > `git describe`.diff && git describe
[02:18:24] jya: in mythtv, you do:
[02:18:48] jya: cd ~/Work/mythtv/git/mythtv/; rm -rf external/FFmpeg ; git reset --hard HEAD ; patch -p2 < default.diff ; cd external/FFmpeg/
[02:18:56] jya: apply the patch generated earlier, like:
[02:19:04] jya: patch -p1 < ~/Work/ffmpeg/n0.8-8523-g8df774b.diff
[02:19:25] jya: go back to the mythtv directory, make distclean, configure, test
[02:20:45] jya: it's going to be much easier for you i believe to bisect ffmpeg that way...
[02:21:17] jya: like for finding the AVI issue , it was 10 git bisect, 10 times above
[02:21:28] jya: so about 10 minutes per step
[02:22:37] Chutt (Chutt! has quit (Read error: Connection reset by peer)
[02:22:42] jya: i know that this method (with the default.diff patch) will work all the way back to 0.25 without having to do any crafty patch along the way
[02:23:09] jya: i've taken all the pain away with that default.diff file
[02:23:22] jya: hope that makes sense, and help you there
[02:25:21] jya: if you're trying to debug subtitles stuff, it won't work as most of our changes to ffmpeg are on the subtitle stuff and I removed all of that
[02:25:31] jya: haven't bored you to death yet ?
[02:27:56] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds)
[02:28:26] taylorr: jya: sorry I'm watching a game right now... I'll digest this at half time :)
[02:29:05] jya: the list of FFmpeg resync are in external/FFmpeg/README.sync
[02:29:38] jya: thats the list of revision resynced since 0.25
[02:32:05] xris (xris! has quit (Changing host)
[02:32:05] xris (xris!~xris@mythtv/developer/xris) has joined #mythtv
[02:33:46] tris (tris! has quit (Excess Flood)
[02:34:34] taylorr: jya: thanks for all that info... it's better than trying to figure out some of these issues by jumping into the ffmpeg code :)
[02:35:48] jya: as a start, what i would do if i were you (not sure what you are tracking)
[02:35:58] jya: is first revert to the last resync point on mythtv side
[02:36:09] jya: there's been 5 resync since 0.25
[02:36:20] taylorr: I'm trying to figure out why we lose video buffers on some content
[02:36:33] jya: you may find that the problem was introduced in a later resync, it would be much easier that way as it narrows the scope of changes
[02:37:02] tris (tris! has joined #mythtv
[02:37:12] jya: like for the AVI, I tested that way that the problem was introduced in the June resync
[02:37:52] jya: though, i have to admit, i wasn't sure the issue was in ffmpeg back then, so i did a git bisect on mythtv code first. identified the issue came from a change in ffmpeg, and started to bisect ffmpeg then
[02:51:13] stichnot (stichnot!~stichnot@ has joined #mythtv
[02:51:13] stichnot (stichnot!~stichnot@ has quit (Changing host)
[02:51:14] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:55:42] taylorr: grrrr... I already updated my dev laptop to pre-0.27
[03:04:54] stichnot: I can't find any good use for DecoderBase::keyframedist. Am I missing something? It feels like a legacy from the days when we could assume constant keyframe distances in a recording.
[03:21:12] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 264 seconds)
[03:24:26] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[03:25:04] Chutt (Chutt! has joined #mythtv
[03:28:23] Kevin`_ (Kevin`_! has joined #mythtv
[03:29:04] Kevin` (Kevin`! has quit (Ping timeout: 246 seconds)
[03:36:04] Kevin`_ is now known as Kevin`
[03:44:54] taylorr: jya: that patch failed against the latest 0.26-fixes... did I need to check out a certain 0.26-fixes?
[03:45:30] taylorr: oops... never mind
[03:47:37] Chutt (Chutt! has quit (Read error: Connection reset by peer)
[04:11:20] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Ping timeout: 246 seconds)
[04:11:33] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[04:12:52] taylorr: jya: are you sure that patch you gave me resets to ea5dab58?
[04:29:17] taylorr: jya: basically if I do "git checkout fixes/0.26" and then apply your default.diff which ffmpeg hash should I be at?
[04:36:00] stichnot (stichnot! has joined #mythtv
[04:36:00] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[04:36:00] stichnot (stichnot! has quit (Changing host)
[04:38:43] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Quit: Leaving)
[04:42:23] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[04:48:21] taylorr: jya: hmmm, looks like maybe "git diff" and "patch" aren't fully compatible.
[04:51:53] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:54:57] fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 244 seconds)
[04:57:06] Chutt (Chutt! has joined #mythtv
[05:20:01] taylorr: I'm getting a number of rejects but the diff file looks good to me
[05:33:04] Vernon_at_work_ (Vernon_at_work_! has quit (Ping timeout: 260 seconds)
[05:43:02] stichnot: danielk22: you probably have the longer-term context for DecoderBase::keyframedist. It looks like a pseudo-random number is chosen for this field based on the recording type and frame rate, then all the keyframe indexes loaded from the DB are multiplied by keyframedist, and then divided again when looking up their values (a nice potential source of floating point errors in the current code btw).
[05:44:17] stichnot: And why do we care about keyframes at all, much less keyframe distance, beyond the fact that it's more convenient to do mpeg2 lossless transcoding at keyframe boundaries, and seeking is fastest when seeking to a keyframe?
[06:24:28] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Ping timeout: 256 seconds)
[06:26:14] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[06:38:47] rsiebert_ (rsiebert_! has joined #mythtv
[06:42:24] rsiebert (rsiebert! has quit (Ping timeout: 272 seconds)
[07:08:54] jya: taylorr: they should be… just need to apply them with the right level in the right directory
[07:09:04] jya: here is the command line I was running:
[07:09:10] jya: to compile after applying the patch
[07:09:52] jya: taylorr: you will get reject, but the one you get can be ignored. there's a constant reject on Makefile
[07:09:58] jya: the one for configure you can ignore
[07:11:35] jya: the git diff you generate while in the ffmpeg original directory, you apply them with -p1 in mythtv/external/FFmpeg
[07:25:18] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[07:27:36] Sharky-AFK is now known as Sharky112065
[07:37:10] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[07:39:04] FabriceMG (FabriceMG! has joined #mythtv
[08:04:45] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:07:31] dekarl1 (dekarl1! has joined #mythtv
[08:07:42] dekarl (dekarl! has quit (Ping timeout: 250 seconds)
[08:11:55] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[08:18:45] Sharky112065 is now known as Sharky-AFK
[08:28:10] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[08:28:16] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[08:36:25] dekarl1 is now known as dekarl
[08:39:47] len_ (len_! has quit (Read error: Connection reset by peer)
[08:49:49] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[08:50:24] bas-t (bas-t! has joined #mythtv
[09:04:33] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:bc92:b8ed:be:226) has joined #mythtv
[09:34:07] bas-t (bas-t! has quit (Quit: Quit)
[11:12:43] stuartm: "This issue has been evident since .26 was in pre-beta." < Yet he only decides to report it after the release :(
[11:19:45] Seeker`: stuartm: what issue was that?
[11:21:45] stuartm:
[11:22:17] stuartm: #11295
[11:22:17] ** MythLogBot **
[11:23:05] Seeker`: useful
[11:23:52] Seeker`: I tried asking this in -users yesterday and got no repsonse: Is ReadReal took > 100ms indicitive of a problem, or more of a "Just so you know..."
[11:24:13] Seeker`: getting a lot of it appearing in my frontend logs
[11:26:48] stuartm: Seeker`: could be either, danielk22 left that debugging enabled after merging the mythsocket branch so that any regressions could be debugged
[11:28:20] stuartm: if you aren't having playback problems at the same time you can probably ignore it for now
[11:28:24] Seeker`: I'm getting dropped frames (I think)
[11:28:38] Seeker`: something is causing an uneven framerate in my playback
[12:46:01] IReboot (IReboot! has quit (Remote host closed the connection)
[12:50:34] IReboot (IReboot! has joined #mythtv
[12:59:17] aloril (aloril! has quit (Ping timeout: 255 seconds)
[13:05:45] aloril (aloril! has joined #mythtv
[13:17:22] stuartm: Seeker`: ok, could be related then, are you running the latest master?
[13:19:44] danielk22: stichnot: keyframedist.. when the PVR-350 was the only MPEG encoder and there was no DTV we recorded the keyframedist (either 12 in PAL countries and 15 in NTSC) and we recorded the keyframe count in the DB (not the frame # as we do now.) The keyframedist support in the decoder is to support recordings of that era.
[13:30:59] tonsofpcs: oh, is that why one of the channels I watch seems to jump? I thought they were just having encode issues...
[13:44:56] zombor (zombor!~zombor__@ has joined #mythtv
[13:44:56] zombor (zombor!~zombor__@ has quit (Changing host)
[13:44:57] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[14:16:59] stichnot: danielk22: I should have said there's actually one use of sorts of keyframedist – a test in MythPlayer::EventLoop() to "// Disable rewind if we are too close to the beginning of the buffer", but the specific value of keyframedist isn't really important.
[14:19:37] Seeker`: stuartm: < 48 hours old
[14:20:18] Vernon_at_work_ (Vernon_at_work_! has joined #mythtv
[14:20:20] Vernon_at_work_ (Vernon_at_work_! has quit (Remote host closed the connection)
[14:20:37] Vernon_at_work_ (Vernon_at_work_! has joined #mythtv
[14:24:53] stichnot: and I also forgot to mention that keyframedist sort of implicitly comes up in the cutlist editor when seek distance is set to "keyframe", though editing is allowed only when a seektable exists
[14:27:16] stichnot: Anyway, all this conditional multiplying and dividing by keyframedist complicates what I'm working on so I'm motivated to clean it up if possible.
[14:45:45] danielk22: stichnot: What is needed to finally get rid of it is regenerating the keyframe maps in the DB that are still based on having the keyframedist. I believe the concept has been fully purged from the recorders and we haven't generated any of these types of key frame maps for some time.
[14:47:59] stichnot: danielk22: do you mean requiring users to run "mythcommflag --rebuild" if they want a reasonable progress bar and seeking? I believe we're currently beta-testing the first part. :)
[14:52:07] stuarta: i did that on 0.26 the other day. worked fine. until i did a lossless transcode, at which point it thought a 10m show lasted 13hrs
[14:53:11] stichnot: stuarta: just curious, did a subsequent mythcommflag --rebuild fix it up again?
[14:54:05] stichnot: if someone could upload one of these old recordings, I would use it for testing
[14:54:39] stichnot: and stuarta, my impression is that our lossless transcoding is pretty much borked these days
[14:54:44] stuarta: stichnot: i've not tried, but that was the reason i did it in the first place. quite a number of these recording where showns as 13hrs+
[14:55:40] stichnot: stuarta: they were all in the 13hr range? any in the 400hr range?
[14:58:54] joki (joki! has quit (Ping timeout: 264 seconds)
[14:59:34] joki (joki! has joined #mythtv
[15:04:05] stuarta: stichnot: not seen any 400hr ones
[15:05:59] stichnot: ok. 400hr happens when ffmpeg reports AV_NOPTS_VALUE as the duration and we try to interpret it as an actual duration
[15:06:01] danielk22: FYI 13hrs is the mpeg dts/pts wrap period...
[15:06:28] stuarta: it's 13:10:xx i think
[15:06:35] stuarta: that i see as a duration
[15:07:57] danielk22: actually I'm wrong 26 hrs is the pts/dts wrap. 13 hrs is the wrap when the pts/dts is accidentally stored in a int32_t rather than a int64_t..
[15:09:09] FabriceMG (FabriceMG! has quit (Quit: FabriceMG)
[15:09:16] Goga777 (Goga777! has joined #mythtv
[15:09:40] danielk22: The pts/dts is 33 bits, so 8589934591 ticks & 90,000 tics per second. 8589934591 / 90000 = 95443 seconds or 26 hours & 30 mins.
[15:10:29] stichnot: so there's probably another sentinel value being interpreted as an actual value
[15:18:48] gigem: stichnot: I've got several old, pvr-x50 recordings, if that's what you're asking for.
[15:27:28] stichnot: gigem: a small one would be nice, thanks. (Maybe I should plug in my old PVR-150 and try generating some myself...)
[15:28:11] stuartm: danielk22: there are a couple of coverity warnings about unchecked return values in ringbuffer & fileringbuffer that should probably be looked at, lseek64 and posix_fadvise – coverity ids 746747–746749
[15:36:20] danielk22: stichnot: I may be wrong, but I think you'll need to go back to an old version to get old style keyframe map. AFAIK We always write frame,location keyframe maps now.
[15:40:51] gigem: stichnot: The smallest ones I have are 30 minutes and are about 1.2 GB. If you don't mind a truncated one, a 5 minute sample should be about 240 MB.
[15:50:23] stuartm: just about small enough to be uploaded to the samples folder :)
[15:50:46] stuartm: without necessitating joining together multiple files at least
[16:05:37] dekarl: danielk22: Do I read that correctly, has been backported to 0.25 in . . . 757ce/mythtv which means I can close as fixed in 0.25-fixes?
[16:05:57] dekarl: (And set the milestone of both to 0.25.x)
[16:08:02] gigem: stichnot:
[16:09:25] Goga777 (Goga777! has quit (Remote host closed the connection)
[16:10:49] danielk22: dekarl: I'd just close that as an unsupported version.
[16:12:40] dekarl: aye, but I'd rather say "update to the supported 0.25" instead (I take it that we support 0.25-fixes until we release 0.27)
[16:14:14] danielk22: dekarl: We only support master + most recent release.
[16:15:57] danielk22: The latest 0.25 might work, but if they run into any trouble...
[17:14:01] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:28:29] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[17:36:38] skd5aner: tonsofpcs: you mentioned that you may have figured the trigger for #11207? I couldn't get it to replicate the other day when I was trying to
[17:41:18] SteveGoodey (SteveGoodey! has joined #mythtv
[17:59:39] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:bc92:b8ed:be:226) has quit (Read error: Connection reset by peer)
[18:03:19] stichnot: gigem: got it, thanks. Duration/position display and seeking currently work perfectly in Master without a seektable.
[18:03:32] brfransen (brfransen!~brfransen@ has quit (Ping timeout: 248 seconds)
[18:04:48] brfransen (brfransen!~brfransen@ has joined #mythtv
[18:05:00] stichnot: Interestingly, mythffmpeg -i puts the duration at 11:15:46.75, whereas ffmpeg -i says 00:06:25.09 (the OSD reports 6:23)
[18:12:10] natanojl (natanojl! has joined #mythtv
[18:13:18] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[18:21:19] Tobbe5178: i have a dev question
[18:21:32] Tobbe5178: related to this: . . . 591af/mythtv
[18:21:38] Tobbe5178: (recording rule templates)
[18:22:14] Tobbe5178: recently i had a big disk crash and lost my main mythtv box so i had to rebuild it from scratch including all config
[18:22:45] Tobbe5178: and apparently this recording rule templates have been introduced that i was unaware of, and auto commflaggning was moved over to the templates
[18:23:07] Tobbe5178: so, if i set auto comflag to on in the default template, when does this overrule the setting in the recording rule?
[18:23:28] petefunk (petefunk!~pfunk@ has quit (Ping timeout: 250 seconds)
[18:23:35] petefunk (petefunk!~pfunk@ has joined #mythtv
[18:23:51] Tobbe5178: both template and the rules have checkboxes so there is no option like "use defaults" in the recording rule
[18:24:33] Tobbe5178: problem i have is that most recordings dont auto comflag
[18:24:41] Tobbe5178: probably those i created via mythweb
[18:24:54] Tobbe5178: so, is it a bug or am i using it wrong?
[18:25:16] Steve-Goodey (Steve-Goodey! has joined #mythtv
[18:26:58] dekarl: wrt PTS/DTS... I have collected some samples of channel switches (time share). They range from "properly changing PMT to point to a different audio and video PID" over "switching the reencoder to a different upstream video stream" to "simply switching from on upstream video stream to another midframe". Where do we collect such samples?
[18:42:22] tris (tris! has quit (Quit: Leaving)
[18:58:59] keylimesoda (keylimesoda! has joined #mythtv
[18:59:12] keylimesoda (keylimesoda! has quit (Client Quit)
[18:59:30] keylimesoda (keylimesoda! has joined #mythtv
[18:59:33] keylimesoda (keylimesoda! has left #mythtv ()
[19:02:35] sphery: Tobbe5178: you want #mythtv-users
[19:07:21] Steve-Goodey (Steve-Goodey! has quit (Quit: Konversation terminated!)
[19:09:56] Steve-Goodey (Steve-Goodey! has joined #mythtv
[19:14:59] tris (tris! has joined #mythtv
[19:21:08] brfransen (brfransen!~brfransen@ has quit (Ping timeout: 272 seconds)
[19:23:50] brfransen (brfransen!~brfransen@ has joined #mythtv
[19:50:51] bas-t (bas-t! has joined #mythtv
[19:55:26] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds)
[19:55:41] danielk22: jya_: I can't reproduce the playback issue with bolt.avi
[19:57:02] danielk22: I even tried myth streaming over wifi from an NFS mounted drive to bump up any roundtrip delay issues.
[19:57:32] danielk22: this is with cd0212131d reverted.
[19:59:30] danielk22: A "mythfrontend -v file --loglevel debug" log might be useful. Then I can compare it to what I see here...
[20:03:26] Guest48558 (Guest48558! has joined #mythtv
[20:06:12] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 248 seconds)
[20:15:24] peper03 (peper03! has joined #mythtv
[20:24:22] peper03: stichnot: Just as a by-the-by, you mentioned the other day about the hardened plastic-like goo in the power adapter. That's almost certainly supposed to be there. It's usually there to provide some stress relief for bigger components like capacitors and inductors. It helps stop the solder joints breaking because of vibrations. You very often find it in power supplies.
[20:25:24] peper03: I think anything that comes out of a capacitor usually looks more chemical-y.
[20:30:05] stuartm: peper03: just thought you might like to know that I found a DVD which is still unplayable with the simplified playback patch, it's not rip-able either, can't even create bit for bit copy with dd
[20:30:25] stuartm: seriously tricky copy protection being used
[20:30:38] jhezer_ (jhezer_! has joined #mythtv
[20:39:30] stichnot (stichnot!~stichnot@ has joined #mythtv
[20:39:30] stichnot (stichnot!~stichnot@ has quit (Changing host)
[20:39:30] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[20:41:50] stichnot: peper03: yeah, the goo didn't look anything like the photos on the web, even if it was very sloppily applied. There was an awful chemical smell inside, and one cap was clearly bulging, so maybe it was just on the verge of a total failure.
[20:43:11] stichnot: btw, I am currently using a D-Link power supply that is only rated for 1.2 amps but seems to be sufficient (until the 2.5 amp replacement arrives tomorrow)
[20:52:31] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[20:52:38] stichnot: The PBB reports the very useful cumulative file size for a display group, but for some reason only if you're on the Delete Recordings screen. Any reason not to include it in Watch Recordings?
[20:52:54] peper03: stichnot: I don't think I've ever seen it applied neatly. I guess that means it's been applied by hand :) If the caps go, the noise on the output can be horrible. At least it gets your attention :)
[20:53:21] stichnot: But not when it's sitting out in the garage :)
[20:53:41] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Excess Flood)
[20:53:43] stichnot: oh, you mean noise encoded in the recording?
[20:54:56] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[20:55:00] peper03: stuartm: No, I meant the noise on the supply voltage. It's supposed to be DC (a flat line if you look at it on an oscilloscope) but without the caps, it'll look anything but flat.
[20:56:07] stichnot: I would be a little less verbose in the file size, e.g. "There are 20 recordings in this display group (98.6GB)."
[20:56:16] peper03: The electronics are designed to expect a nice, clean DC input. Instead of getting, say 5v, it gets a voltage that jumps about all over the place and most probably keeps dropping too low for the chips to work correctly.
[20:56:27] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Excess Flood)
[20:57:09] peper03: stuartm: I presume that DVD didn't play before the patch either? As long as the patch doesn't introduce regressions, I'm happy. Happy to look at why any given DVD still doesn't work. as well though :)
[20:59:19] bas-t (bas-t! has quit (Quit: Quit)
[20:59:29] peper03: I've found that Cars 2 pauses every time it hits a new chapter. Haven't had chance to look why yet. Probably going to be difficult over the next couple of weeks as my PC's is in the guest room, which is now being used. Certainly no late night sessions for the next couple of weeks :)
[21:05:33] peper03: stichnot: <OT>The first image on this page shows more or less what I mean</OT>: . . . /188328.aspx
[21:06:38] danielk22: peper03: Is that a Disney movie? In my LG Blueray player Disney titles always have trouble at chapter boundaries. I just assumed it was poor mastering. Much like half the TV shows for kids have horrible interlacing artifacts.
[21:10:46] peper03: danielk22: Yep. I didn't notice any warnings or errors in the logs. It was more coincedence really that I happened to be looking at the logs as it was playing and noticed the video freezes for a couple of seconds as it hits a new chapter.
[21:11:54] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[21:12:40] peper03: It's protected by ARccOS but, as I say, I didn't notice any errors in the logs. I think if there had been errors, the player would have bombed back out to the MythVideo menu (which is also something that would be nice to catch if possible).
[21:15:20] peper03: One thought came to me about copy protection schemes that intentionally encode bad sectors – potentially that could cause issues with a read ahead cache. If you're at sector 'N' and the read ahead cache reads the next, say, 5 sectors but sectors > N+3 are bad, that could cause playback to fail even if we would have jumped somewhere else before we'd actually hit those sectors.
[21:16:04] peper03: The read-ahead cache would be trying to help but would end up causing read errors that we wouldn't have had if we only read the actual sectors we definitely needed.
[21:17:08] peper03: stuartm: Maybe that's the cause of the problems you're having? I don't know exactly how the cache is implemented so it might not be causing us problems but it's probably something to investigate.
[21:19:20] stuartm: peper03: no it doesn't play without the patch, it has one VOB that seems to be deliberately undecryptable, problems range from the DVD playing a 21 second blank screen clip with four chapters but looping back on the first chapter, menus don't display properly and I get audio but no video at all if I do somehow manage to start playback
[21:20:51] stuartm: libdvdread: Error cracking CSS key for /VIDEO_TS/VTS_01_1.VOB (0x00000990)!!
[21:21:32] stuartm: I requested a replacement disc just in case it was just scratched, but the replacement displayed the same problems
[21:23:37] peper03: stuartm: Does the CSS lib claim to be able to decrypt all DVDs or are there maybe some discs it's known to not be able to play? I guess that DVD isn't playable on any other program either?
[21:25:07] peper03: I had one DVD that the CSS lib took an awful long time to find the keys for. It worked eventually but I think it took 10 seconds or more. That's another UI "issue". There's no feedback to the user that anything is happening. The keys are searched for before we show 'Please Wait'.
[21:25:56] sraue_ (sraue_! has joined #mythtv
[21:26:50] stuartm: I don't think the problem is with decss
[21:27:01] sraue_ is now known as sraue
[21:27:11] sraue (sraue! has quit (Changing host)
[21:27:12] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[21:31:03] stuartm: kaffeine (xine backed) just refuses to even try playing it, vlc gets to the menu and displays that fine but won't play the video, displays the same problems as we do although it handles the errors better
[21:31:31] jya_: danielk22: you need to play it using storage group
[21:31:32] jya_: like so:
[21:32:04] jya_: myth://Videos@
[21:32:19] jya_: if you play over smb , hfs or direct it plays jut fine
[21:33:17] jya_: wagnerrp: Did you see that post about the guy with AirPlay, the fronted never listens on the IPv4 address.
[21:33:49] jya_: danielk22: I do: mythavtest myth://Videos@
[21:33:53] stuartm: peper03: vlc does allow changing the title from the menu though, and of the dozens of titles available, apparently all identical, some play
[21:34:27] jya_: can reproduce it on all my machines (ubuntu linux, iMac, macbook air) whenever they connect over wifi. Doesn't matter the speed of the wifi link
[21:34:50] jya_: like my iMac is connected 130Mbit/s over wifi, with wifi router 1m away from it
[21:36:40] peper03: stuartm: That definitely sounds like copy protection. Cars 2 also has 99 titles. Have you tried googling the DVD to see if you can find any more information? Sounds almost more like a problem with libdvdread/nav.
[21:37:47] peper03: stuartm: Jumping to a specific title isn't possible at the moment in Myth, is it? I've not found it in the menu.
[21:41:08] stuartm: peper03: not for DVD, I implemented it for Blu-ray but at the time I assumed it was already there for DVD
[21:43:57] ** jya_ and then studios wonder why people source media from "elsewhere" when you can't even play original DVD... **
[21:52:35] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[21:53:30] peper03: stuartm:Just tried googling a bit. One page from 2008 suggests there can be issues on some discs when the disc and drive are for different regions The other from April said there was a regression in libdvdcss2 with some hardware. Don't know if that affected all discs or just some.
[21:53:43] jya (jya! has joined #mythtv
[21:53:43] jya (jya! has quit (Changing host)
[21:53:44] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[21:54:10] peper03: stuartm: What version of libdvdcss2 do you have installed?
[21:57:19] stuartm: 1.2.12
[21:58:27] Steve-Goodey (Steve-Goodey! has quit (Quit: Konversation terminated!)
[21:58:51] peper03: Ok, that contains the fix. 1.2.11 was the bad one apparently.
[22:00:23] stuartm: the disc is the UK (region 2) rental version of Margin Call
[22:07:48] peper03: Hmmm. Google doesn't seem to give much away.
[22:13:22] peper03: I wonder if they're doing something sneaky with filenames? I saw something about two versions of VIDEO_TS.IFO, one having the upper Unicode byte set to something other than 0x00. libdvdread (I think) just blindly stripped the upper byte off to convert to ascii and happened to use the 'wrong' file for navigation.
[22:13:42] peper03: I think that was fixed though.
[22:16:52] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds)
[22:19:27] peper03: stuartm: Actually, that error message might be a complete red herring. As long as we don't try to navigate to that title, we should be ok. On the other hand, if the beginning of that file is unreadable, but the middle or end is ok, that might be enough to cause libdvdcss to give up trying to get the key, which then bites us when we later try to jump to a later sector.
[22:30:09] stuartm: there's only one version of VIDEO_TS.IFO
[22:30:11] stuartm:
[22:31:07] stuartm: and if you're thinking that those file sizes total more than a DVD is capable of holding, (hell even a blu-ray) you'd be right
[22:32:21] peper03: yup, that's the same thing as on the Cars2 DVD, although that has 99 titles!
[22:32:54] peper03: VTS_01_1.VOB is very small, though.
[22:33:07] stuartm: peper03: this lists ~99 titles in the vlc menu, even if the DVD structure doesn't suggest it
[22:33:36] peper03: Still, big enough to hold a cell or two that just set some registers
[22:34:40] stuartm: to me it seems like they aren't just employing one new trick, but a whole bunch of them
[22:35:14] peper03: stuartm: Do you see anything from either CELL_CHANGE or VTS_CHANGE in the logs that would indicate we're trying to read that file?
[22:36:56] peper03: Quite possible. If libdvdcss gives up as soon as it gets a bad sector, putting one at the start of the file would work nicely. I don't know if that's how libdvdcss works, just throwing ideas out there.
[22:42:14] stuartm:
[22:43:21] stuartm: eventually ends up at menu, but with no background visible, just the highlight
[22:44:27] stuartm:
[22:47:49] peper03: stuartm: Just for laughs, can you try a different video decoder? Something other than VDPAU? One of my DVDs gives me more or less just black video with VDPAU selected. The highlight is visible and it can be played but there's basically no video. OpenGL works fine.
[22:52:19] stuartm: same deal with opengl
[22:54:06] peper03: damn!
[22:56:20] peper03: I forget the exact correlation between the files and the logical structure but the logs seem to indicate that it's trying to play something from that file. There's certainly references to title 1 and VTS 1. I don't see any real error messages though.
[23:00:30] natanojl (natanojl! has quit (Ping timeout: 265 seconds)
[23:12:13] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[23:19:07] peper03: stuartm: Setting DVDCSS_VERBOSE=2 when running MythFrontend gives quite a bit of extra info from libdvdcss. Might give us a clue.
[23:20:41] peper03: stuartm: Did you try ripping it with ddrescue at all? I haven't used it much but I've seen it referred to quite a few times.
[23:22:47] stuartm: only additional information when using dvdcss vebose mode is
[23:22:55] Chutt (Chutt! has quit (Read error: Connection reset by peer)
[23:24:10] stuartm: trying ddrescue now
[23:25:27] stuartm: it will be good if I can rip it, since I don't want to hold onto this rental for too long, especially not with Christmas a week away and absolutely nothing on television
[23:28:13] peper03: Only thing might be that the rip doesn't allow you to reproduce the problem. Not got too much experience in this area. But you never stop learning :)
[23:31:31] peper03: That log does seem to suggest that it hit the end of the file before it could find the key. The file is 1.8M but it stops at block 3360 as it's not an MPEG block. 3360*512 is ~1.7M. I wonder if they've corrupted part of the file too?
[23:35:13] peper03: Maybe not. It starts at block 2448. (3360–2448)*2048=1867776. DVDs actually use 2048 byte blocks if I remember correctly.
[23:35:33] stichnot (stichnot!~stichnot@ has joined #mythtv
[23:35:36] stichnot (stichnot!~stichnot@ has quit (Changing host)
[23:35:36] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[23:36:51] ** tonsofpcs wonders what's going on with MPEG blocks **
[23:37:47] peper03: tonsofpcs: Me too :)
[23:39:09] tonsofpcs: heh
[23:43:44] Vernon_at_work_ (Vernon_at_work_! has quit (Remote host closed the connection)
[23:44:02] Vernon_at_work_ (Vernon_at_work_! has joined #mythtv
[23:45:42] jhezer_ (jhezer_! has quit (Ping timeout: 264 seconds)
[23:51:50] peper03: Ok, I need to call it a night. I'll keep an eye on the archives and get back on here when I get the chance.
[23:55:20] peper03 (peper03! has quit (Quit: Konversation terminated!)

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