:: #mythtv

Daily chat history

Current users (81):

aloril, Anssi, anykey_, Beirdo, Ben64, brfransen, bsilvereagle, CaCtus491, Captain_Murdoch, Chutt, clever, coling, Cougar, danielk22, dblain, dekarl, ElmerFudd, f33dMB, fetzerch, foobum, foxbuntu, ghoti, gregL, GreyFoxx, Guest18522, IReboot, J-e-f-f-A, jams, jarle, jarryd, jheizer, joe___, joki, jpabq, jpabq_, jpharvey, jst, jwhite, kc, kenni, Kevin`, knightr, kurre2, kwmonroe, laga, monkeypet, Mousey, mrand, MythBuild, MythLogBot, neufeld_AFK, NightMonkey, Peitolm, Peps, poptix, purserj, rsiebert_, Seeker`, seld, Sharky112065, skd5aner, Slasher`, SmallR2002, sphery, sraue, stuarta, superm1, sutula, taylorr, tgm4883, toeb, tonsofpcs, tris, Vernon_at_work, wagnerrp, wahrhaft, wolfgang1, xavierh_, XDS2010__, yoyolala, _charly_
Wednesday, December 12th, 2012, 00:00 UTC
[00:00:31] skd5aner: Captain_Murdoch: did you ever follow up with Beirdo on this thread?
[00:01:23] stichnot: jya: the user might not be very happy that an important show gets recorded on a sucky tuner thanks to live TV. On the other hand, sucky is probably better than nothing.
[00:01:39] skd5aner: Captain_Murdoch: I've just discovered that it's impacting me as well
[00:01:46] jya: what I do find very confusion is that you're watching liveTV, there's another show about to be recorded. if you have 3 free recorders, none of them in use now or later.. yet, you are asked if you want to change what you're currently watching because there's a recording about to happen… why bother having more than one card then
[00:02:43] stichnot: that sounds like case 1, right? gigem is suggesting no prompt in that case, which sounds like an improvement over what you're describing today
[00:02:53] jya: stichnot: I honnestly think that we shouldn't have to worry about sucky tuner or tuner quality. There are facts that could be assumed, one of them being that his hardware is properly working
[00:03:43] jya: the more I go in life, the more I find that the option to not even bother presenting option that are extremely unlikely to be used, or can be achieved differently
[00:04:20] jya: so here, the user gets to watch the recording in progress. he can manually change channels
[00:05:47] stichnot: jya: for me, sucky=SD, e.g. PVR150 instead of HDPVR. But you're right – a careful setup (or even better, carefully chosen defaults) of priorities, live TV order, etc. would probably make it far easier to make good automatic downstream choices.
[00:06:26] jya: stichnot: but this is already catered for. you have the priority for livetv and priority for recordings
[00:06:33] jya: you make them inverse
[00:06:45] jya: so you start watching livetv on your pvr150
[00:07:01] jya: or better, stop being a tight arse and get another hdpvr :)
[00:07:08] stichnot: yep :)
[00:08:06] jya: isn't it funny that we expect users to be annoyed that they have to buy another piece of $50 hardware (or whereabout)…. Yet, it is accepted to be all good, that in order to properly handle all cases, thousand of dollars worth of development time be yse
[00:09:12] dekarl (dekarl! has quit (Ping timeout: 255 seconds)
[00:09:22] jya: i can't recall the amount of time spent looking at troubleshooting a 20c audio card on the cheapest motherboard there is...
[00:09:35] jya: anyhow.. that's my rant for the day
[00:10:25] skd5aner: gigem: I agree exactly with jya's line of thinking above... either there's a direct conflict, or there isn't... if there's a direct conflict, then prompt... if there's a free tuner available, then leverage the free tuner and never prompt
[00:10:27] stichnot: except that an HDPVR plus lease of another STB plus another IR blaster plus whatever else is a lot more than $50 and crosses over into many myth users' pain points
[00:10:33] skd5aner: anything else seems too pervasive
[00:12:21] skd5aner: stichnot: lets assume someone does something dumb and overlaps a PVR-150 and and HD-PVR on the same video source (i.e. channels) – and the HD-PVR is far superior option, yet that's what's being leveraged for Live TV... In that case, you simply leverage whatever tuner is next in line for the recording, imho
[00:12:33] dekarl (dekarl! has joined #mythtv
[00:12:56] dekarl: stichnot: I've got at least one DVD around where each VOB of the main title resets the PTS at the beginning (makes for interesting effects when joining them together with a simple vobcopy)
[00:13:06] skd5aner: as mentioned above, live tv priority/order (although not exactly robust in it's current form) and/or tuner priority/order should take over
[00:13:46] jya: skd5aner: I can already imagine the 12 lines menu of possible choice: 1-record program using this recorder, and switch livetv to the same program on a lesser card.. refer to http://blah/wiki for more information). 2-Do like above, but go to mythtv-setup to change the card priority so it doesn't happen again … etc :)
[00:14:50] dekarl: reminds me to get the samples over to Bei rdo with all variants of stream tricks / issues when the stations switch inside the same service (e.g. branching out to regional news by switch to 7 different audio/video streams instead of one shared pair, or simply pushing down a different stream down the same PID when stations switch in time share)
[00:15:33] Mousey: Goodbye Internets! Time to go home and play some more Steam games under Linux! :D
[00:15:38] skd5aner: I know it's blaspemy to compare mythtv to a commercial dvr, but as a lowest common denominator, no multi-tuner commercial dvr in the world would prompt a user to exit live tv because a recording needs to use a preferred tuner – unless all tuners need to be leveraged for scheduling
[00:15:40] Mousey (Mousey! has quit (Remote host closed the connection)
[00:15:57] skd5aner: I see no reason why MythTV should try and overly think that – different tuner qualities or not
[00:16:36] stichnot: I'm pretty sure that if we remove the prompt, we will have either a mob of people complaining that they are getting randomly kicked out of Live TV for no apparent reason, or a different mob of people complaining that random recordings are being missed (without making the Live TV connection)
[00:16:47] skd5aner: I solve this by ensuring that I have a unique video source for my unique video cards, and limit overlap in channels to a very few
[00:16:53] stichnot: of course we already have the first mob for different reasons... :)
[00:17:21] jya: stichnot: I don't think anyone is asking to remove the prompt except for the case where an obvious alternative is possible
[00:17:39] jya: Personally, I consider liveTV to have the same priority as a recording
[00:17:58] jya: what I'm doing now is what I want to do now...
[00:18:29] skd5aner: for example, my "analog-sd" source ties just to my PVR-500 – for channels 2–99. My "ditigal-QAM" source ties to my QAM tuners, to get my dozen or so local networks in HD. my "analog-HD" source ties to all channels not in the first 2, and my my "Digital-CC" source ties to my prime – which right now is basically QAM only, but otherwise woudl be everything
[00:18:45] jya: being prompted when there's an immediately available alternative to record makes no sense to me
[00:19:32] skd5aner: stichnot: I don't think the prompt should be removed... it should prompt only when Live TV will truely prevent a schedule recording from happening. Right now, there's a "bug" that can cause the prompt to show even when other valid tuners are available
[00:19:46] jya: and if I wanted to watch very high quality show (by quality I mean bitrate/resolution), I wouldn't use FTA anyway
[00:20:16] jya: skd5aner: I guess the issue is what understanding of availability mean...
[00:20:46] skd5aner: Well, FTA (OTA here in the US) is high-bitrate/resolution typically now since we're digital broadcast and it's generally uncompressed compared to how cable co's rebroadcast it compressed usually
[00:20:56] jya: indeed, if you start saying that a card is better, and a recording is more important, then yes, that it prompts make sense… but I personally think it's going to far
[00:21:59] jya: skd5aner: here in Oz, the more it go with FTA, the more the quality drop. With mpeg2 channels only, and a narrow choice of multiplex. everytime they add a new channel, they do so by reducing the quality of all the others
[00:22:00] skd5aner: jya: yea... in my case, because of how I have my sources configured, in addtion to the number of cards I have, it'd be nearly impossible for me to run in to a case of "worse" not better
[00:23:42] jya: danielk22: I've reverted your 3924df87c7691852741b596f50311eac46f930ab and only that
[00:23:57] jya: and the duration of the colbert stop being in the 400+ hours
[00:24:10] jya: still not the right duration, but it's not an insane number either
[00:24:49] peper03 (peper03! has quit (Quit: Konversation terminated!)
[00:25:26] stichnot: jya: presumably its the same bogus (but not completely insane) duration that ffmpeg/mplayer/vlc all report
[00:27:26] jya: i guess I need to check the fix Captain_Murdoch added after danielk22 change to bypass the problem it introduced, and find out another case where av_estimate_timings needs to be called
[00:29:41] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[00:30:34] jya: it looks like it's not just a matter of calling av_estimate_timings that is important...
[00:30:44] jya: but the order it's called and do it before av_update_stream_timings_video(ic);
[00:35:15] stichnot (stichnot!~stichnot@ has joined #mythtv
[00:35:15] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[00:35:15] stichnot (stichnot!~stichnot@ has quit (Changing host)
[00:39:48] skd5aner: I am seeing some weird durations occastionally with recent recordings
[00:39:56] skd5aner: like 30 min recordings showing up as 4 mins
[00:39:59] skd5aner: in the OSD
[00:40:22] stichnot: jya: I don't see any commit message for your reversion. Are you pushing to master or your branch?
[00:40:40] jya: oh.. I'm only working on my local copy… just debugging
[00:40:45] jya: haven't pushed anything
[00:40:50] stichnot: ah ok
[00:41:21] jya: actually, interestingly, for that particular video, the av_estimate_timings need to be called twice to get a meaningful value
[00:41:24] jya: so I'm tracing that
[00:41:34] jya: I have no idea what it does, or what it does
[00:44:14] stichnot: I recall that a recent problem with the current ffmpeg is sometimes funky playback if you skip back to the beginning or play through some sort of garbage or discontinuity in the file. e.g. #11159 . I see that often on hdpvr recordings and I should test the resync on my production system.
[00:44:14] ** MythLogBot **
[00:45:20] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Ping timeout: 255 seconds)
[00:51:11] jya: funny, I need to do av_estimate_times -> av_update_stream_timings_video -> av_estimate_timing to get a meaning full value
[00:55:08] jya: stichnot: VLC for me shows a duration of 00:00
[00:57:36] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[00:58:48] stichnot: ah, you're right, same here
[01:00:05] stichnot: skd5aner: can you check what "mythffmpeg -i <recording>.mpg" says about the duration, and the same for ffmpeg?
[01:00:40] skd5aner: stichnot: yes, trying to fix my channel lineup – will check later tonight
[01:01:10] jya: stichnot: this patch change what duration is being displayed
[01:01:11] jya:
[01:01:28] jya: see on how I have to call av_estimate_timings twice?
[01:01:40] jya: remove either, and it shows the 400+ hours
[01:01:53] MythBuild: build #236 of master-f17–32bit is complete: Success [3build successful] Build details are at . . . t/builds/236
[01:01:55] MythBuild: build #3250 of master-freebsd-64bit is complete: Success [3build successful] Build details are at . . . /builds/3250
[01:02:32] jya: the myth mpegts code seems to completely ignore the CC tracks
[01:03:35] jya: vlc sees 9 streams in that TS
[01:04:32] MythBuild: build #152 of master-debian-wheezy-64bit is complete: Success [3build successful] Build details are at . . . t/builds/152
[01:05:05] stichnot: jya: I see, bizarre
[01:07:52] jya: actually, it's just a matter of calling av_estimate_timings twice, no need for av_update_stream_timings_video
[01:08:22] taylorr: stichnot: it's interesting that rerunning mythcommflag --rebuild corrects the duration... this might mean that it's getting corrupted or we are using it even though it's never been generated before
[01:09:10] taylorr: or we are relying on ffmpeg and it's not going to work with discontinuities
[01:09:45] stichnot: taylorr: I thought it just scans the entire file to calculate the true duration and puts it in the DB, which takes precedence at playback over ffmpeg's value
[01:09:47] MythBuild: build #4417 of master-linux-64bit is complete: Success [3build successful] Build details are at . . . /builds/4417
[01:10:05] taylorr: the player should be checking to see if the duration field has been set by mythcommflag (or recorder)... if it doesn't exist we use ffmpeg to determine length
[01:10:18] taylorr: stichnot: yes, that's what it does
[01:10:43] taylorr: I thought you meant it already had a markup table but the duration was wrong
[01:11:04] stichnot: yeah, so we agree. The only mystery is how jya's DB value got set without running mythcommflag
[01:11:48] stichnot: well, the markup table includes other items like bookmark
[01:12:34] taylorr: the assumption for old recordings was that the duration field wouldn't exist so we'd use the old method of frames/fps
[01:17:41] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds)
[01:17:58] MythBuild: build #17 of master-linux-64bit-clang is complete: Success [3build successful] Build details are at . . . ng/builds/17
[01:18:35] jya: with this av_estimate_timings, it will be impossible to get some help from the ffmpeg folks, as this is a private API we weren't ever supposed to use...
[01:18:45] jya: documentation is virtually non-existent too
[01:25:13] lvmer (lvmer! has joined #mythtv
[01:26:48] Sharky112065 is now known as Sharky-AFK
[01:27:29] MythBuild: build #439 of master-linux-64bit-icc is complete: Success [3build successful] Build details are at . . . c/builds/439
[01:58:39] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Quit: Leaving)
[01:59:46] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[02:00:49] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Client Quit)
[02:01:06] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[02:01:43] lvmer (lvmer! has quit (Quit: Leaving.)
[02:06:25] jya: stichnot:
[02:06:43] jya: I have all the streams recognised just like using stock ffmpeg
[02:08:40] jya: this was done by applying some changes from the original ffmpeg mpegts code to the mythtv one
[02:13:45] gigem: jya: This is part of a series of changes to remove unnecessary settings and have MythTV do the right thing(*) without extra direction from the user. *Doing the right thing is defined by us and those who disagree will just have to live with it. In the process, I'm re-evaluating any existing or possible new behavior that I think merits it. This is one of those cases.
[02:13:48] gigem: jya, skd5aner, stichnot: As already noted, the current (and future) code WILL move a recording to an "equivalent", free tuner. That's not the question. The question is whether or not to move a recording without user direction to a later time where it probably will record if nothing else changes or to a "sucky" tuner that is currently free.
[02:13:50] gigem: I don't know of any commercial tuner that has the sucky tuner issue because all of their tuners are equivalent. In this day and age, I suspect most MythTV users don't have it either. However, if they do, they probably don't want it used except as a last resort. Personally, I think the behavior should be the same as with normal scheduling — prefer a later showing on a non-sucky tuner over an earlier
[02:13:52] gigem: showing on a sucky tuner.
[02:13:54] gigem: The question then boils down to whether or not to let the user know there is a later showing currently available and have them make the informed decision.
[02:14:39] gigem: Discuss amongst yourselves. I've got to run away again.
[02:16:22] stichnot (stichnot! has joined #mythtv
[02:16:22] stichnot (stichnot! has quit (Changing host)
[02:16:22] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[02:18:44] taylorr: jya: do you have a patch of the mpegts changes?
[02:19:03] jya: i do, but that's on the devel/resync branch
[02:19:13] jya: which has the latest ffmpeg
[02:21:43] taylorr: does the 0.26 branch have the missing code too?
[02:22:59] skd5aner: gigem: yea... good arguments... I guess it'll be impossible for mythtv to guess what tuners are "good" and "sucky" unless the user relies on an explicit tuner priority, or the default tuner order (or the recording/livetv ordering stuff)...
[02:24:08] jya: taylorr: I haven't touched master or fixes/0.26
[02:24:21] jya: i'm currently working in a separate branch with a new ffmpeg resync
[02:24:22] skd5aner: gigem: I think the best mythtv can do is assume that all things are created equal unless explictely defined by a user not to be, and in that case – wouldn't it make sense to just move to schedule at the current time rather than find a later time on the same/equivalent tuners currently in use?
[02:24:43] skd5aner: gigem: ^ all things being equal...
[02:26:03] skd5aner: gigem: now, lets say they're not, and there are either tuner or channel priorities in the mix – then the question is, should it record on the lessor priority channels/tuners or reschedule? Tougher one to answer, but off the top of my head, I might still lean towards recording now. I'd have to sleep on that one
[02:27:53] skd5aner: gigem: whatever happens, I still think prompting the user would be something to avoid unless there is no other option. Prompting them to say "would you like to reschedule this for later, or record on a different set of tuners" is probably not a good idea imho
[02:29:17] jya: its a bit bizarre, that using the same mpegts code as the original ffmpeg, mythffmpeg doesn't detect the number of channels for the AC3 stream
[02:33:26] danielk22: jya: If calling that function twice is doing something we should put it back with some comment on the the line explaining that it only works properly if called the second time.
[02:34:09] danielk22: It's probably that calling that function the first time has a side effect of initializing something that is used the second time around.
[02:34:27] jya: danielk22: that's for this particular video, I'm still not convinced it's actually worth bothering about, or even normal.
[02:34:47] jya: tracing the code, I couldn't see anything obvious why a 2nd time would work
[02:36:27] jya: the code that seems to make a difference between the mythtv-mpegts and stock mpegts, is commit 6faf0a21 in ffmpeg) where: Add support for Sections in PMT and Parse mpeg2 SL descriptors. was added
[02:38:18] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[02:41:53] rsiebert_ (rsiebert_! has joined #mythtv
[02:44:35] rsiebert (rsiebert! has quit (Ping timeout: 240 seconds)
[02:44:35] jya: I really wonder if we shouldn't be better off porting all our changes to the mpegts code a long time agon, back to an up to date mpegts code
[02:47:28] jya: seems like a lot of work, and to be done by someone with a clue on what he's doing. that excludes me
[02:53:57] stichnot: jya: I agree that this colbertclip no longer looks like something to get right at this point, though it could be a bit of a torture test for the DB segment work
[02:55:39] jya: interestingly, when I replace the mpegts code for the original one, the video playing has nothing to do with colbert
[02:55:47] jya: but it's an infomercial
[02:56:08] jya: it's probably playing that different 1280x720 stream that doesn't show currently
[02:56:21] jya: and it crashes shortly after that
[02:59:28] zombor (zombor!~zombor__@ has joined #mythtv
[02:59:28] zombor (zombor!~zombor__@ has quit (Changing host)
[02:59:28] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[03:03:14] skd5aner: stichnot: perhaps a video that stuartm might be interested in leveraging for his collection of clips for regression testing
[03:03:34] skd5aner: see if things get better/worse in the future
[03:33:11] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[03:49:49] Captain_Murdoch: skd5aner, we talked about it, but I don't think either of us got to a solution. I think we decided on allowing the caller to specify a timeout to the MythDownloadManager::download() call.
[03:50:31] skd5aner: Captain_Murdoch: gotcha – I submitted a ticket on the bug so it doesn't get lost. Thanks
[03:53:40] taylorr: jya, Beirdo, danielk22, stichnot: I noticed Mark is following a stable branch for libav... I know up until recently that wasn't an option for ffmpeg but is it time we did the same? I thinking taking snapshot of master is asking for too much trouble these days.
[03:54:51] jya: taylorr: that's libav project though...
[03:55:03] jya: didn't see any branches in ffmpeg
[03:55:07] jya: that is
[03:55:30] taylorr: I believe they have a 1.0 branch now
[03:56:07] jya: there's a tag
[03:56:10] jya: same on
[03:56:16] jya: don't see any branch
[03:56:52] taylorr: it's called release/1.0
[03:57:19] jya: ah yes.. you're right
[03:57:22] taylorr: look at the "heads" list
[03:57:34] jya: could definitely sync against a release/1.0 branch
[03:57:38] taylorr: like I say... it's just now becoming a possibility
[03:59:03] Captain_Murdoch: gigem, not sure if it's been thought of or suggested earlier (or if we have it already), but what do you think about the idea of a 'LiveTV priority' setting to correspond to the scheduled recordings priority. that could affect the automated decision or change the default action if the menu prompt timed out. if we already have something like that, well then that shows how little I use LiveTV. :)
[03:59:29] taylorr: jya: I wonder how xbmc determines when to sync
[04:00:03] jya: what do you mean?
[04:00:11] jya: ah ok.. got you
[04:00:26] jya: do they even sync?
[04:00:33] jya: or ffmpeg is just an external ?
[04:00:38] taylorr: like do they do like we've been doing since the start and take a snapshot of master or do they follow a specific release
[04:00:55] taylorr: they have their own copy of ffmpeg like we do
[04:01:22] jya: ok
[04:01:37] taylorr: jya: they also maintain a "patches" directory which is quite useful that has all their changes against the stock code
[04:02:22] taylorr: you could also just sync with them and use their patches :)
[04:02:43] jya: most of the changes that are complicated are the one related to mpegts
[04:02:51] jya: and they wouldn't care about that functionality
[04:03:28] taylorr: sure, we'd have changes that don't need... at least until they get their native pvr functionality going full steam
[04:04:32] taylorr: it actually might be a good thing for xbmc to have to support broadcast tv
[04:04:53] jya: do they now ?
[04:05:02] taylorr: have pvr support?
[04:05:37] taylorr: I'm not sure if it's been released but I think it's at least in the works... I could totally be wrong here.. I don't follow xbmc very closely
[04:05:48] jya: I wonder if I should revert my entire merge
[04:09:02] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[04:10:46] taylorr: jya: it would be nice if we could somehow bisect ffmpeg changes.... probably quite difficult with our local changes and possible API changes
[04:11:23] jya: i do do git bisect on ffmpeg, but that only works with a problem I can also reproduce using ffplay
[04:11:54] jya: I'm fairly certain all the issues we are seeing have more to do with our "rough" use of ffmpeg
[04:13:54] taylorr: quite possible, we have samples from skd5aner that causes lost video buffers... the libav error messages in mythavtest don't occur in ffplay
[04:16:33] skd5aner: fyi – xbmc is trying to build a frontend pvr functionality that ties in to existing backends, such as mythtv...
[04:17:12] skd5aner: and
[04:17:46] skd5aner: I don't really follow xbmc either, but this has been a pretty hot topic recently in the -users channel and mailing list
[04:17:47] fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:21:00] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 260 seconds)
[04:21:31] taylorr: jya: Mark pointed out that we are setting a field differently than ffplay when we setting a video context... in avformatdecoder we set enc->err_recognition = AV_EF_COMPLIANT ... this is no longer set in ffplay... not sure why it was set in the first place
[04:22:28] taylorr: it didn't help skd5aner's sample but it might be something to try for other issues
[04:23:04] danielk22: taylorr: I can answer that :) It used to be that if you didn't set enc->err_recognition = AV_EF_COMPLIANT ffmpeg wouldn't bother to decode the last 1/4 of the image. Of course that was a bug which has hopefully be fixed upstream long ago.
[04:23:05] taylorr: also, one area that could be very different is our custom video buffer routines
[04:23:35] taylorr: danielk22: awesome, of course a comment would have been nice :)
[04:25:05] taylorr: unfortunately I don't understand the video buffer internals and haven't taken the time to learn... someone like Mark would be much better for that stuff
[04:25:56] danielk22: I can explain the video buffer stuff. But not right now, I should be in bed...
[04:27:13] taylorr: danielk22: ok, sleep is important... past my bed time too
[04:27:41] skd5aner: me too.. that's lots of lost sleep manhours
[04:27:44] taylorr: that code should probably be reviewed again sometime
[04:28:43] taylorr: danielk22: and to be clear, I'm not talking about the video buffer management but the internals of the video buffer
[04:59:47] Captain_Murdoch: wagnerrp, regaring your -users mailing list post about LiveTV not getting added to free space calculations, were you looking at MainServer::BackendQueryDiskSpace()? If so, I think you read it backwards, removing LiveTV from the groups QStringList allows it to be used since the groups list in that context is a list of groups that aren't looked at.
[05:14:37] taylorr: jya: this is what both libav and ffmpeg say about their releases: "At irregular intervals Libav makes releases that represent snapshots of Libav at the moment the release branch was cut. Between major releases point releases will appear that add important bug fixes but no new features. Note that these releases are intended for distributors and system integrators. Users that wish to compile from source themselves are strongly encouraged to consider u
[05:14:37] taylorr: sing the development branch (see above), this is the only version on which Libav developers actively work. The release branches only cherry pick selected changes from the development branch, which therefore receives much more and much faster bug fixes such as additional features and security patches."
[05:16:49] jya: taylorr: that doesn't make me feel very confident about using the release branch tbh… as they are just snapshots, so next time there's another new release, it will be just as painful as upgrading to master of the time
[05:16:54] jya: except that it is done less often
[05:17:28] jya: so what are we? distributor/system integrator or users that compile from sources themselves?
[05:18:29] taylorr: dunno, from looking at the activity on the stable branches they do get a lot of fixes back ported though
[05:19:01] taylorr: when we snapshot we generally don't know what to backport... they do.
[05:20:13] taylorr: I agree that that sync'ing will not be any easier
[05:22:13] taylorr: doesn't make sense for them to say that the release branch doesn't get as fast bug fixes... if it's broken on the release branch then it's most likely broken on master or they haven't backported which they need to do anyways
[05:25:17] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[05:26:27] jya: often I do that, I fix a bug on master and wait a little while for things to settle before backporting it to branch
[05:31:05] brfransen (brfransen!~brfransen@ has quit (Ping timeout: 255 seconds)
[05:31:47] brfransen (brfransen!~brfransen@ has joined #mythtv
[05:47:09] gigem: Captain_Murdoch: I think one of my initial ideas for live TV scheduling might have included priority in the way you suggested. It never got implemented because someone, whom I can't remember, contributed the current code. The current code mostly works as if live TV has the lowest scheduling priority. It would work exactly like that if we allow the scheduler to automatically choose later showings or "sucky"
[05:47:11] gigem: inputs. I'd rather not change the live TV as lowest priority bit because that's where I, and I think most of us, believe it should be and it's one less setting for us to support.
[05:47:41] gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.3.8)
[05:48:59] gigem (gigem! has joined #mythtv
[05:49:00] gigem (gigem! has quit (Changing host)
[05:49:00] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[05:55:13] Goga777 (Goga777! has joined #mythtv
[06:18:03] skd5aner (skd5aner! has quit (Read error: Connection reset by peer)
[06:18:20] skd5aner (skd5aner! has joined #mythtv
[06:32:38] Goga777 (Goga777! has quit (Remote host closed the connection)
[07:07:05] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[07:08:33] fetzerch_ (fetzerch_!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 244 seconds)
[07:16:03] FabriceMG (FabriceMG! has joined #mythtv
[07:18:02] pheld (pheld! has joined #mythtv
[07:57:41] FabriceMG (FabriceMG! has quit (Quit: FabriceMG)
[08:02:41] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[08:08:38] dekarl (dekarl! has quit (Ping timeout: 255 seconds)
[08:13:39] dekarl (dekarl! has joined #mythtv
[09:02:37] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:80b3:f15:b662:f67f) has joined #mythtv
[09:54:40] jya: taylorr: I've pushed a new branch devel/resync-stable10, that contains a resync to ffmpeg release/1.0 branch
[10:18:09] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[10:24:41] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[10:33:35] Guest37385 (Guest37385! has quit (Read error: Connection reset by peer)
[10:42:40] stuarta: jya: do you need the buildslaves to track any of the resync branches?
[10:49:54] f33dMB (f33dMB!~f33dMB@ has quit (Quit: changing servers)
[10:50:35] f33dMB (f33dMB! has joined #mythtv
[10:50:35] cecil (cecil! has quit (Quit: Konversation terminated!)
[10:51:48] ElmerFudd (ElmerFudd!~le@ has quit (Ping timeout: 245 seconds)
[10:53:39] stuarta: jya: it's pretty easy todo
[10:53:47] stuarta: won't take long either
[10:55:57] ElmerFudd (ElmerFudd! has joined #mythtv
[10:56:35] cesman (cesman! has joined #mythtv
[10:56:35] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[10:56:35] cesman (cesman! has quit (Changing host)
[11:18:05] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[11:18:47] jya_: stuarta: that would help yes… prevent in breaking master
[11:19:00] jya_: just resync-stable10
[11:19:04] jya_: i'm going to drop the other
[11:25:24] stuarta: okay, when i have a moment i will set it up
[11:25:45] stuarta: i'll just do the currently working master builders on that branch
[11:32:14] jya_: weird.. I have a file here, following the ffmpeg resync (either master or release/1.0) it finds an extra stream with codec MJPEG… which is bogus… What this reveal is that myth is trying to play that stream even though there's an earlier H264 stream… how does myth decide which video stream to play? the last one only ?
[11:34:40] jya_: oh.. actually, even stock ffmpeg finds it too...
[11:39:35] IReboot (IReboot! has quit (Remote host closed the connection)
[11:42:45] IReboot (IReboot! has joined #mythtv
[11:47:07] jya__ (jya__!~jyavenard@mythtv/developer/jya) has joined #mythtv
[11:47:11] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Read error: Connection reset by peer)
[11:49:27] Sharky-AFK is now known as Sharky112065
[11:53:14] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[11:59:15] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[12:09:26] bas-t (bas-t! has joined #mythtv
[12:38:37] Sharky112065 is now known as Sharky-Sleep
[12:55:33] stuartm: jya: yes it uses the first video stream it finds, see AvFormatDecoder::ScanStreams() ln 1952, or comment 3 lines earlier – // Set the default stream to the stream that is found first in the PMT
[12:56:04] jya__: stuartm: well, not really… In the order it finds h264, aac, mjpeg
[12:56:11] jya__: yet it attempts to play the mjpeg
[12:57:08] jya__:
[13:00:29] stuartm: do you have a -v playback log? I'm curious what order it's iterating the streams
[13:01:49] stuartm: also last night someone mentioned that ffmpeg was returning a stream id of -1 for some audio, if that's what is happening here for the video streams it would explain why it's using the last stream instead of the first
[13:03:07] stuartm: really we need a video equivalent of AutoSelectTrack(), choose the highest resolution, highest bitrate stream that we're capable of decoding – that last bit would allow us to fallback to the lower res version on underpowered devices
[13:04:16] jya__: it's definitely iterating them as h264, aac, mjpeg
[13:04:49] jya__: as it doesn't know mjpeg (in mythcodecid.cpp) it displays an error and select CODEC_ID_MPEG2
[13:10:41] jya__: is there a way to select a video track like you select an audio track?
[13:11:13] stuartm: no
[13:12:45] stuartm: vast majority of files we see have only one video track, but they are becoming increasingly common especially stuff like trailers, instead of distributing 2, 3 or 4 files at different resolutions/bitrates they ship one combing a high res and a very low res stream
[13:13:16] jya__: stuartm:
[13:13:35] stuartm: I've also got an example here of a file containing an empty video stream, i.e. whatever they used to author it screwed up
[13:13:37] jya__: this mjpeg is the artwork for the trailer
[13:13:46] jya__: download that trailer from apple site a long time ago
[13:14:20] stuarta: ah, that's one of those 0 bitrate channels
[13:15:04] stuartm: jya__: AFD: Stream #2, has id 0x0 codec id MJPEG
[13:15:04] ** MythLogBot **
[13:15:06] jya__: this is using the new ffmpeg, and I've made a small mod so it doesn't consider the mjpeg stream as unknown and try to use mpeg2 instead
[13:15:25] stuartm: the stream id is zero, which places it before the H.264 with a stream id of 0x1
[13:16:01] jya__: I see
[13:16:19] jya__: by stream id I thought you meant the #0.0 stuff reported by ffprobe
[13:16:19] ** MythLogBot **
[13:17:12] jya__: well, I can do it the ugly way for the time being, in ScanStreams, I have a test if the codec is mjpeg and skip it alltogether
[13:17:18] stuarta: MythLogBot: be quiet
[13:17:20] jya__: provided we can't handle it anyway
[13:17:21] stuartm: jya__: it should be the same, something is wrong here :/
[13:18:30] jya__: which stuff determine the stream id ?
[13:18:33] jya__: is that ffmpeg?
[13:18:52] lvmer (lvmer! has joined #mythtv
[13:20:38] jya__: stuartm: I guess we should be using this:
[13:20:39] jya__: . . . 21dcac09aff9
[13:22:29] jya__: that gives me an idea
[13:23:47] stuartm: hmm, seems that's a red herring, we shouldn't be using that value anyway, it's only printed in the log and ignored elsewhere
[13:29:36] sl1ce (sl1ce! has quit (Ping timeout: 240 seconds)
[13:29:42] sl1ce (sl1ce! has joined #mythtv
[13:29:56] stuartm: jya__: the following patch should add the A/V Stream index as determined by ffmpeg –
[13:35:22] stuartm: in fact, better yet –
[13:38:44] stuartm: sorry, make that this –
[13:40:04] stuartm: I'm betting that that last patch fixes it
[13:41:14] stuarta: haha
[13:41:42] stuartm: actually, needs moving higher up :( Need more coffee
[13:41:49] dmfrey (dmfrey! has joined #mythtv
[13:43:10] stuarta: 4th time lucky?
[13:45:11] stuartm: hopefully –
[13:45:25] stuartm: even if it doesn't work, it's in the right neighbourhood ;)
[13:45:48] stuarta: send it with a map, might find its own way home
[13:47:56] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[13:52:20] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 248 seconds)
[13:57:12] Jordack (Jordack! has joined #mythtv
[13:57:14] stuartm: jya__: can you upload the sample to the account I just emailed, or post a link here? I can test the changes myself and prevent future regressions
[13:57:35] jya__:
[13:57:43] jya__: i'm working on another solution
[13:58:04] jya__: that will select the video stream like it does for the audio one
[13:58:10] jya__: testing now
[14:00:27] stuartm: ok, the patch I provided should still be necessary to prevent scan streams opening up every video stream and trampling all over itself in the process
[14:00:44] jya__: i've actually removed that part completely
[14:00:58] jya__: the initialisation of the video now being done in the autoselectvideos
[14:01:24] jya__: i see that with your patch you init the video on the first stream
[14:01:29] jya__: and then ignore the others
[14:01:42] stuartm: fwiw, my patch does work against that sample
[14:02:02] jya__: yes… because as the h264 was encountered first, that's what it uses
[14:02:28] stuartm: jya__: yeah, my patch just fixes the code to work as it was apparently intended, it doesn't make it any smarter, but that should also mean we can safely backport my fix
[14:02:40] jya__: indeed
[14:03:19] stuartm: auto-detection is much better but I'd hesitate before backporting it to 0.26/0.25
[14:04:13] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[14:05:18] stichnot (stichnot! has joined #mythtv
[14:05:18] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[14:05:18] stichnot (stichnot! has quit (Changing host)
[14:07:25] taylorr: jya__: I was informed that it's an attachment stream... check for AV_DISPOSITION_ATTACHED_PIC being set and ignore
[14:07:47] jya__: ah ! even better !
[14:08:20] jya__: at least for that particular stream
[14:09:10] danielk22: As a rule don't we ignore all the streams we don't know how to decode?
[14:09:27] jya__: danielk22: here it has a type of video
[14:09:32] jya__: so it's handled as a video string
[14:09:35] jya__: stream
[14:10:10] danielk22: ouch! ok. Most of the wacky streams are of type data. Including extra MHEG video streams IIRC.
[14:10:24] bas-t (bas-t! has quit (Quit: Quit)
[14:11:09] dmfrey (dmfrey! has quit (Remote host closed the connection)
[14:12:52] dmfrey (dmfrey! has joined #mythtv
[14:17:08] jya__: hum...
[14:17:15] jya__: looking at something weird in there
[14:17:18] jya__: just realised
[14:17:27] jya__: everytime a video stream is encoutered
[14:17:41] jya__: it does nitrate += enc->bit_rate
[14:17:58] jya__: why keep increasing the bitrate ?
[14:18:35] jya__: that particular video with colbert, has two video streams in there.. that could explain why the duration is way too much
[14:23:18] stichnot: cumulative bitrate of the entire file?
[14:24:03] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[14:24:04] MythBuild (MythBuild! has quit (Remote host closed the connection)
[14:24:14] MythBuild (MythBuild! has joined #mythtv
[14:25:24] jya__: what for ?
[14:25:26] danielk22: That would be my guess. We use the cumulative bitrate to tell the ringbuffer how to buffer.
[14:25:50] danielk22: At least initially until it starts seeing the true bitrate via reads.
[14:28:07] stuarta: MythBuild: force build ffmpeg-debian-wheezy-64bit now
[14:28:08] MythBuild: build #0 forced
[14:28:08] MythBuild: I'll give a shout when the build finishes
[14:28:18] stuarta: MythBuild: force build ffmpeg-f17–32bit now
[14:28:19] MythBuild: build #0 forced
[14:28:19] MythBuild: I'll give a shout when the build finishes
[14:28:23] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 255 seconds)
[14:28:32] stuarta: MythBuild: force build ffmpeg-freebsd-64bit now
[14:28:40] MythBuild: build #0 forced
[14:28:40] MythBuild: I'll give a shout when the build finishes
[14:28:44] stuarta: MythBuild: force build ffmpeg-linux-64bit now
[14:28:44] MythBuild: build #0 forced
[14:28:44] MythBuild: I'll give a shout when the build finishes
[14:28:52] stuarta: MythBuild: force build ffmpeg-linux-64bit-clang now
[14:28:55] MythBuild: build #0 forced
[14:28:55] MythBuild: I'll give a shout when the build finishes
[14:29:02] stuarta: MythBuild: force build ffmpeg-linux-64bit-icc now
[14:29:03] MythBuild: build #0 forced
[14:29:03] MythBuild: I'll give a shout when the build finishes
[14:29:23] stuarta: jya__: all the builders are now going on the ffmpeg resync branch
[14:29:28] jya__: thanks
[14:30:11] stuarta: i've skipped all the ones we already know are failing on master
[14:30:21] stuarta: or offline
[14:32:55] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[14:33:37] Captain_Murdoch: gigem, fine by me. not having the setting makes the user make that choice on-demand based on the current show they're watching live, which also has advantages to both us (coding) and the user (choice).
[14:40:22] danielk22: stuarta: FYI you can PM build requests to MythBuild..
[14:40:43] stuarta: or i could have use #mythtv-commits
[14:41:03] stuarta: me--
[14:41:11] danielk22: Heh, I didn't know there was a #mythtv-commits
[14:43:33] stuarta: :)
[14:47:16] joki (joki! has quit (Ping timeout: 248 seconds)
[14:48:20] joki (joki! has joined #mythtv
[14:53:32] MythBuild: Hey! build ffmpeg-linux-64bit #0 is complete: Failure [4failed compile core]
[14:53:32] ** MythLogBot **
[14:53:32] MythBuild: Build details are at . . . bit/builds/0
[14:58:52] jya__: stuarta: which buildbot is which ?
[14:59:22] jya__: weird that it doesn't link with libmythswresample
[14:59:24] stuarta: most of them are self explanatory
[14:59:41] stuarta: that one is beirdo's ubuntu box
[14:59:58] stuarta:
[15:00:29] stuarta: although i believe he needs to update the slave info as he upgraded it to the new LTS release recently
[15:00:48] jya__: no i mean, how do you know which one build which branch?
[15:01:07] jya__: ah sorry
[15:01:13] jya__: i didn't see the ffmpeg bit
[15:01:16] jya__: 2AM..
[15:01:22] jya__: need to go to bed
[15:01:43] MythBuild: Hey! build ffmpeg-freebsd-64bit #0 is complete: Failure [4failed compile core]
[15:01:43] ** MythLogBot **
[15:01:43] MythBuild: Build details are at . . . bit/builds/0
[15:02:04] stuarta: oh. all the builders ffmpeg-* are building devel/resync-stable10
[15:02:10] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 250 seconds)
[15:02:31] jya__: i don't get it… why is it building for me if it makes those type of errors?
[15:03:08] stuarta: the buildslaves use a clean build dir every time. ie. no installed libs
[15:03:20] jya__: so do i
[15:03:34] stuarta: you don't already have a master build installed?
[15:03:45] MythBuild: Hey! build ffmpeg-linux-64bit-clang #0 is complete: Failure [4failed compile plugins]
[15:03:45] ** MythLogBot **
[15:03:45] MythBuild: Build details are at . . . ang/builds/0
[15:05:02] jya__: stuarta: no… i build in a jail
[15:05:14] stuarta: it's a little odd, since it does build it
[15:05:17] jya__: and on my mac, i use the osx-packager which clean the whole lot first
[15:05:42] stuarta: LD libswresample/ <-- that's it built
[15:06:41] jya__: and has a link to it
[15:07:22] danielk22: In the link line I don't see a -L../../external/FFmpeg/libswresample
[15:07:52] jya__: in ? it's line 90
[15:08:10] jya__: ah sorry, that's in libmyth
[15:08:48] jya__: do all the lib linking to libmyth require to have the path to the library used by lib myth?
[15:09:44] MythBuild: Hey! build ffmpeg-f17–32bit #0 is complete: Failure [4failed compile core]
[15:09:44] ** MythLogBot **
[15:09:44] MythBuild: Build details are at . . . bit/builds/0
[15:10:12] danielk22: jya: yep
[15:10:58] danielk22: Just the -L part
[15:11:55] danielk22: So look at line 761, it adds ../../external/FFmpeg/libswscale but not the -lswscale
[15:12:25] jya__: yes… but uses directly libswcale
[15:12:37] jya__: that sucks...
[15:12:38] MythBuild: Hey! build ffmpeg-linux-64bit-icc #0 is complete: Failure [4failed compile plugins]
[15:12:38] ** MythLogBot **
[15:12:38] MythBuild: Build details are at . . . icc/builds/0
[15:12:53] jya__: but what i don't get then
[15:13:03] jya__: lib myth, link libavformat
[15:13:17] jya__: why isn't there a link to libavformat then to libmythbase
[15:15:47] danielk22: I don't understand the question
[15:17:02] jya__: before my change
[15:17:15] jya__: lib myth was linking to libavcodec and libavutil
[15:17:28] jya__: libmythbase is linked against libmyth
[15:17:29] jya__: h
[15:17:52] jya__: yes, in libmythbase, there's nothing set about how to use libavcodec or libavutil
[15:18:21] danielk22: If libmythbase doesn't call anything that needs a libavcodec or libavutil the linker doesn't require it.
[15:18:38] jya__: so why is it when I add libswresample to lib myth, when I added it exactly like libavformat, now libmythbase complain
[15:19:56] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[15:19:59] jya__: it shouldn't make any use of it either… the code using libswresample is a static function, that is only used in libmythtv
[15:20:54] danielk22: If it still is in libmyth, libmyth needs it.
[15:20:59] jya__: (in config.mak, the LDFLAGS contains a rlink
[15:21:15] jya__: and so is libavcodec and libavutil
[15:21:58] jya__: what I don't understand is why it would need to set the path for libswresample, but not libavcodec or libavutil
[15:22:08] jya__: they are using in an identical fashion, in the same code
[15:22:08] MythBuild: Hey! build ffmpeg-debian-wheezy-64bit #0 is complete: Failure [4failed compile core]
[15:22:08] ** MythLogBot **
[15:22:08] MythBuild: Build details are at . . . bit/builds/0
[15:22:58] jya__: i see that libavcodec is in the list of -L
[15:23:06] jya__: now need to find out where this one is defined
[15:23:30] danielk22: probably
[15:24:33] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 276 seconds)
[15:25:16] danielk22: We put pretty much everything in there even though many of the programs only use a subset of libs, it's just much simpler that way and doesn't add much to the linking time.
[15:27:59] danielk22: We're down to 11 warnings in the icc build, down from over 700 a month ago :)
[15:35:49] jya__: stuarta: I pushed a change to the branch, yet it doesn't recompile
[15:36:00] jya__: i spoke too fast!
[15:40:03] dmfrey (dmfrey! has quit (Remote host closed the connection)
[15:40:31] stuarta: yeah, there is a delay
[15:41:21] stuartm: danielk22: fwiw, this fixes the 'always use first video stream' logic –
[15:41:36] stuartm: I think it's worth using for 0.25/0.26 even if not 0.27
[15:41:43] dmfrey (dmfrey! has joined #mythtv
[15:42:31] jya__: i'm fairly confident it will be unnecessary in 0.27
[15:43:09] stuartm: we still enumerate all the streams but only bother opening the first, there was no code to allow fallback to another stream if we couldn't decode the first one, so nothing gets broken there
[15:43:13] jya__: that is until i find why it segfault
[15:43:47] jya__: i don't even see the need to open all the streams to be honest while we're in the scan
[15:43:56] jya__: sorry, open all the codec
[15:44:16] stuartm: jya__: that's why the patch stops us doing that
[15:45:01] jya__: stuartm: sure… what i'm saying is that i've changed that logic completely already. i've implemented a AutoSelectVideoTrack() method, that search for the best video track, and only open it then
[15:45:27] danielk22: stuartm: Will that still work with MHEG secondary video and will we still set add the extra video bitrates to the total bitrate correctly?
[15:46:24] danielk22: BTW We should get an MHEG sample with extra video streams into the collection..
[15:46:38] stuarta: danielk22: the mheg video tends to be in a private stream
[15:46:46] jya__: danielk22: yes, it still add the bitrate
[15:46:59] danielk22: cool, it sounds safe to me
[15:47:10] jya__: what stuartm has done is simple not select the stream as soon as we find one
[15:47:21] stuartm: danielk22: I've not yet encountered any mheg stuff which uses a second video stream, instead it just re-tunes to another channel entirely
[15:47:48] stuartm: danielk22: and yes, as jya__ notes it will still account for the bitrate
[15:48:47] danielk22: We can possibly get a sample from Dave Mathews. My guess is something like a horse racing channel might do multiple independent video streams for the various angles they show.
[15:49:35] danielk22: I remember that was added separately, so we can probably find the ticket & reporter, but I assume it was Dave.
[15:49:44] stuartm: everything after that point in the code is redundant if we're not going to be decoding, and worse it modifies a whole bunch of members with the wrong values e.g. codec_is_mpeg, video_codec_id would all be overwritten with the values of the second video stream even though we'd be decoding the first
[15:51:31] jya__: now that is weird:
[15:51:31] jya__: ../../libs/libmythbase/mythconfig.h:9:0: warning: "av_restrict" redefined [enabled by default]
[15:51:58] jya__: when attributes.h that redefines it has #ifndef av_restrict
[15:54:00] Chutt (Chutt! has quit (Read error: Connection reset by peer)
[15:55:14] Chutt (Chutt! has joined #mythtv
[15:55:36] danielk22: jya: It is complaining about mythconfig.h which does not have the #ifndef av_restrict
[15:55:45] jya__: sure
[15:56:11] jya__: but mythconfig.h is included right at the top of the file, well before avcodec.h (that includes attributes.h
[15:57:31] jya__: interesting… myth archive breaks too, in some code I didn't touch at all. seems to be missing a #include time.h
[15:59:12] danielk22: jya: look at the cc608reader.cpp warning, while mythconfig.h is first in ringbuffer.h, ringbuffer.h is defined as the third mythtv include in mythplayer.h
[16:03:23] jya__: i don't see any of those doing an include on ffmpeg before mythconfig.h is included
[16:05:05] jya__: i guess it's just too late for me to think clearly. good night everyone
[16:05:34] stuartm: danielk22: digging through the blame output I can't see any commits on this area of the code which relate to mheg/second video streams, there was a commit by Captain_Murdoch back in 2006 to fix this bug originally, but since then a bunch of additional stuff was added to ScanStreams and AVFormatDecoder that broke his fix
[16:07:40] danielk22: jya: did you look at audiooutputsettings.h ?
[16:58:53] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[17:28:55] dmfrey (dmfrey! has quit (Remote host closed the connection)
[17:29:42] stichnot (stichnot!stichnot@nat/google/x-wbevgpeigdadifiu) has joined #mythtv
[17:29:42] stichnot (stichnot!stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:29:42] stichnot (stichnot!stichnot@nat/google/x-wbevgpeigdadifiu) has quit (Changing host)
[17:30:05] dmfrey (dmfrey! has joined #mythtv
[17:31:21] stichnot: jya: I tried colbertclip under 0.24. mythffmpeg still reports 2 streams instead of 4. During playback, it doesn't even bother trying to display a progress bar. so this clip is an unfortunate red herring in my opinion, though a nice torture test for the future
[17:40:58] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:45:11] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv
[17:46:56] wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv
[17:47:19] wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Read error: Operation timed out)
[17:48:50] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has quit (Client Quit)
[17:49:51] jpabq_ (jpabq_!~quassel@mythtv/developer/jpabq) has joined #mythtv
[17:59:06] dekarl: sphery: just put poisonous person in your killfile (the list of people you are going to kill ;)
[18:00:10] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:80b3:f15:b662:f67f) has quit (Read error: Connection reset by peer)
[18:10:45] dmfrey (dmfrey! has quit (Remote host closed the connection)
[18:11:56] dmfrey (dmfrey! has joined #mythtv
[18:14:43] stichnot: danielk22: what is the purpose of writing ProgramInfo::i18n("All Programs") instead of just tr("All Programs") ?
[18:21:53] stichnot: (this happens several times in programs/mythfrontend/playbackbox.cpp)
[18:25:39] danielk22: Take a look at [24094f94]. It removes a bunch of code duplication for the recording group name translation and avoids translations being different in different parts of the UI. We needed to be able to translate stings coming from the database, and having a bunch of if (db_group=="All Programs") group = tr("All Programs"); else if (db_group=="Default") group = tr("Default); littering the code led to inconsistent translations.
[18:25:54] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[18:27:31] danielk22: The ProgramInfo::init_tr() makes sure all the various strings are translatable, and then we can just use tr() in ProgramInfo::i18n() to translate the strings after that.
[18:28:57] danielk22: So it isn't for ProgramInfo::i18n("All Programs") that i18n() exists, it is for ProgramInfo::i18n(groupname) that it exists.
[18:29:43] danielk22: Using it for "All Programs" too just avoids the translator needing to translate it multiple times.
[18:30:02] jarle (jarle! has quit (Remote host closed the connection)
[18:30:17] natanojl (natanojl! has joined #mythtv
[18:30:29] stichnot: danielk22: thanks. So does something like this look reasonable? ProgramInfo::i18n("All Programs – %1").arg(current_group_filter)
[18:31:13] danielk22: Yep, just add that string in init_tr() as well.
[18:32:14] jarle (jarle! has joined #mythtv
[18:32:15] stichnot: ah, I had assumed that init_tr() was some Qt thing :)
[18:32:32] danielk22: I guess under display_rec_groups = at about line 4382.
[18:32:50] danielk22: heh, kind of, but it is our function.
[18:33:22] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[18:43:16] danielk22: stichnot: In this case I think using tr() would be fine though. This isn't a string we'd ever pull from the DB...
[18:44:29] danielk22: It's really there for the "Live TV" "Default" and "Deleted" groups which we do save to the DB.
[18:49:24] Mousey (Mousey! has joined #mythtv
[18:53:35] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[19:05:43] peper03 (peper03! has joined #mythtv
[19:07:52] Goga777 (Goga777! has joined #mythtv
[19:11:01] stichnot: danielk22: here's what I did – . Hopefully that works with the translation layer. I thought it's better to put the new string in a separate "group" because in this case "All Programs" doesn't refer to the name of a special recording group, but rather to the set of all programs from a particular recording group.
[19:13:37] danielk22: looks fine to me.
[19:24:13] wagnerrp_ is now known as wagnerrp
[19:29:10] dmfrey (dmfrey! has quit (Remote host closed the connection)
[19:35:54] sphery: stichnot: I meant to reply to you, yesterday, but you disappeared before I got a chance. I do like "All Programs – <group name>" better (which you mentioned on your list message), but ideally we'd come up with a better way of indicating the top of the list than by making users look for a specific name--whether it's through indentation or icons (or some kind of hierarchical view, like in Windows Explorer or whatever) or something better a UI ...
[19:36:00] sphery: ... guy might come up with (like Apple's bounce-back when at the end of a list--but, obviously, not that since Apple patented it and we don't have $1B to give them ;).
[19:36:07] Goga777 (Goga777! has quit (Remote host closed the connection)
[19:36:30] Goga777 (Goga777! has joined #mythtv
[19:36:30] Goga777 (Goga777! has quit (Read error: Connection reset by peer)
[19:37:22] sphery: I always find the top of the list easily because on all the themes I use, PageUp/Down stop when they hit the end, then I need an Up/Down to roll past it, so I hadn't ever needed to use the words to find the top. But, since that seems to be why you prefer "All Programs" instead of the group name, it would be nice to come up with something better (whether we stick with "All Programs – <groupname>" or not).
[19:37:57] sphery: I'm guessing either your themes use a different scroll style or you don't use PageUp/Down (and only use Up/Down).
[19:41:40] wagnerrp: dblain: tgm4883 was asking if there is anything in the service definition in the Services API that denotes an input as required or optional
[19:42:02] wagnerrp: i couldn't find any, and i'm assuming any undefined parameter is passed through as a null constructed object
[19:42:12] wagnerrp: and left up to the underlying function whether or not that is valid input
[19:44:30] stichnot: sphery: I also benefit from PgUp/PgDn not wrapping, but I guess my brain just likes the comfort of seeing a fixed string/image that doesn't depend (strongly) on the group filter. (My theme's scrollbar indicators are not very noticeable.)
[19:45:19] stichnot: I was thinking that some alternative indentation, color, etc. would also be a nice way of replacing the "All Programs – " string
[19:45:41] stichnot: but I don't feel like enhancing the UI :)
[19:45:43] dmfrey (dmfrey! has joined #mythtv
[19:45:47] stuartm: sphery: the PgUp/Down behaviour isn't themable, it will always stop at the list top/bottom by design
[19:47:31] sphery: ah, I thought maybe that was dependent on wrap style or scroll style or something
[19:48:52] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[20:05:28] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Ping timeout: 265 seconds)
[20:07:57] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[20:09:45] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[20:11:15] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Read error: Connection reset by peer)
[20:11:31] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[20:13:15] Jordack (Jordack! has quit ()
[20:24:29] kth (kth!~kth@unaffiliated/kth) has joined #mythtv
[20:36:58] jya__ (jya__!~jyavenard@mythtv/developer/jya) has quit (Quit: jya__)
[20:58:40] peper03: stuartm, danielk22: I've just created ticket #11288 with a proposed patch for cleaning up the start of DVD playback. I'd appreciate if you could look over the changes in AVFormatDecoder in particular. Maybe there's a better way of doing it, or if you see any side-effects I may have missed.
[20:58:40] ** MythLogBot **
[20:59:50] sraue (sraue!~stephan@xbmc/staff/sraue) has quit (Quit: Ex-Chat)
[21:04:01] zombor (zombor! has joined #mythtv
[21:04:02] zombor (zombor! has quit (Changing host)
[21:04:02] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[21:05:24] peper03: jpharvey: If you are able to try out that patch in place of the one you attached to #11171 I'd be very interested to check that it works with the DVDs you were having problems with.
[21:05:24] ** MythLogBot **
[21:07:00] SteveGoodey (SteveGoodey! has joined #mythtv
[21:12:45] dekarl: danielk22: do you mind if I turn off CRC checking for Dishnet longterm EIT (at least as far as it collides with ECM/EMM in DVB/ATSC/SCTE) after all it was disabled prior to the last CRC "fix" and causes excessive logging (>100 lines per second) for some users. (I think it might make stuff like #10947 worse)
[21:12:45] ** MythLogBot **
[21:15:10] dekarl: the patch would be basically #10495
[21:15:10] ** MythLogBot **
[21:18:20] sl1ce (sl1ce! has quit (Quit: Konversation terminated!)
[21:19:25] jpharvey: peper03: I'll try over the next few days
[21:19:51] peper03: jpharvey: Great. Thanks!
[21:20:47] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has quit (Ping timeout: 246 seconds)
[21:24:08] peper03: stuartm: I suspect the problem described in #9842 is the same as I fixed in the patch for #11275. The description certainly fits and the 'DVDRB: Asking for a still frame' line in the log matches what you see when you have a still frame with audio.
[21:24:08] ** MythLogBot **
[21:24:08] ** MythLogBot **
[21:25:19] natanojl (natanojl! has quit (Read error: Operation timed out)
[21:25:45] sl1ce (sl1ce! has joined #mythtv
[21:27:20] dekarl: Can MythDownloadManager download a file to a SG on the MBE? Here is the "download channel icon and store it in mythconfdir" part . . . ata.cpp#n165 I'd like to change the call to MythDownloadManager so it stores the file in SG ChannelIcon instead and then change the update of the channels table to refer to the SG instead of the local file on the backend.
[21:27:36] stuarta (stuarta!~stuarta@mythtv/developer/stuarta) has joined #mythtv
[21:34:56] zombor (zombor!~zombor__@kohana/developer/zombor) has quit (Remote host closed the connection)
[21:36:24] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[21:44:29] dmfrey (dmfrey! has quit (Quit: Ex-Chat)
[21:46:14] stuartm: peper03: that's a simpler patch than I imagined, the non-avf changes parts look fine to me, especially the OpenFile removals, as I commented the other night that stuff was just wrong
[21:47:33] stuartm: I can't see anything wrong with the AVF changes, danielk22 might suggest that they are done another way*, but they shouldn't affect anything but DVD
[21:48:17] stuartm: * we might want to refactor a little so that the DVD specific bits can be moved into AVFDVD
[21:48:39] peper03: stuartm: It's simpler than *I* thought it was :) By the time I'd traced the relationships between MythPlayer, AVFormatDecoder and DVDRingBuffer and figured out how the data actually got from A to B via C, D and a quick stop-off at Y, I had convinced myself the patch was bigger :)
[21:49:26] stuartm: I'd keep any refactor separate though, since that is more likely to break things than the patch alone
[21:50:09] peper03: Yeah, I'm not *completely* happy with the 'm_processFrames' work around/kludge but it seems to work.
[21:50:29] stuartm: peper03: going to do a little testing of the patch now, but the real test will be some of the rental DVDs I'll be receiving over the new few weeks
[21:52:06] peper03: There are a few more things that need cleaning up in the ring buffer too. I noticed with the 'palettetest.iso' image that the menu is shown 4:3 instead of 16:9. Once you select one of the menu options it gets it right. I found that's not a flaw of my patch, it just a flaw that the patch is exposing :) I have a 'real' DVD that exhibits the same behaviour without the patch.
[21:52:19] peper03: It's handled all the DVDs I've thrown at it so far :)
[21:52:36] Captain_Murdoch: dekarl, RemoteDownloadFile() and RemoteDownloadFileNow() in libmythbase/mythcoreutil.cpp take a URL, Storage Group name, and destination filename. the non-Now() version sends out events to let you know the status and when it's done, the Now() version is blocking.
[21:53:37] Captain_Murdoch: dekarl, I was using the non-Now() version in the Theme Chooser to download to the MBE first, but commented out that code temporarily when trying to fix the race condition causing problems with the theme reload.
[21:53:53] Captain_Murdoch: race condition in the UI, not the MDM.
[21:54:09] stuartm: peper03: in my experience TV series DVDs tend to expose the most problems, I don't actually own many of those but I rent plenty – plus rental DVDs tend to employ more copy-protection methods such as empty titles and I'd like to check that trusting the navigation works for those
[21:54:20] dekarl: Captain_Murdoch: ty, do we have a helper function for generating random/hashed filenames? (thinking about http:/xxx/icon.png vs http://yyy/icon.png which collide atm)
[21:54:22] Captain_Murdoch: MDM is used on the MBE to download the file. those calls are just wrappers for mythproto commands.
[21:55:42] dekarl: sounds like a plan. It'll break download via MFDB called from mythtv-setup while the backend is stopped, but that's no problem as it can get the icons on the next run of MFDB :)
[21:55:43] stuartm: peper03: of course it would help testing if I'd kept a record of which DVDs had issues, unfortunately I'll need to go through them all twice – once with and once without the patch :)
[21:55:45] jya: stuartm: I woke up thinking about your change that prevent scanning for video streams… i have a few videos here where it will just not work, like the colbert video that has been talked about here in the past few days. The proper video stream is actually the last one. I have thought of another way to select which stream to play that isn't intrusive and will handle such case
[21:55:45] Captain_Murdoch: not sure, if you're downloading chanid icons, perhaps just use the chanid or callsign or something prepended. the Video Library may have something like that, but I don't know of anything specific since it mainly uses the movie/tv DB IDs as filename prefixes.
[21:56:47] jya: stichnot: It's actually good that it only find two streams… Because if it found the 4 there are, we wouldn't play colbert here but some informatial
[21:56:47] dekarl: prepending the chanid sounds like an idea. gets a copy or two but completely avoides the filename-extension-preservation stuff
[21:57:21] stuartm: jya: yeah, as I said last night it's not a fix for those cases, it just makes the code behave as it did in earlier releases (~ 0.21), we absolutely should have some video stream auto-detection stuff in there going forward
[21:58:13] stichnot: jya: OK. Before now, I was never aware of that infomercial stream...
[21:58:53] peper03: stuartm: I've just tried it with Cars 2. That uses ArcOS copy protection. No problem :)
[21:58:55] stuartm: jya: I'm not going to mind if anyone implements a more complete fix :)
[21:58:57] jya: well, and that infomercial stream make myth crash after a few seconds, it only plays the first 2–3s
[22:00:32] jya: pfff. got to go to that work I'm involved with… I just can't be bothered anymore :(
[22:02:11] jya: allright...
[22:02:14] jya: see ya.
[22:05:03] peper03: stuartm, danielk22: If you find any problems or have any issues with the patch, I read the archives so even if I'm not online, I'll see it.
[22:36:14] sraue (sraue!~stephan@xbmc/staff/sraue) has joined #mythtv
[22:39:17] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[22:54:22] jya_: danielk22: can you check why myth archive doesn't build on the buildbot.. I had the issue on my mac, it was just just a matter of adding a #include <time.h> but here it doesn't fix it… . . . s/logs/stdio
[22:54:39] len (len! has joined #mythtv
[22:55:02] len is now known as Guest18522
[22:55:09] jya_: a bit different on linux
[22:55:10] jya_: . . . s/logs/stdio
[22:56:11] jya_: i don't even understand why myth archive wouldn't build now, when I haven't touched it nor any of the headers it uses
[22:59:23] kth (kth!~kth@unaffiliated/kth) has quit (Quit: Leaving.)
[23:00:21] stichnot: jya_: when switching between branches, I was having mytharchivehelper compile problems until I wiped out the myth include dir and reinstalled
[23:00:42] stichnot: in case that's related here...
[23:00:54] jya_: stichnot: that's on the buildbot, they are supposed to wipe clean the system...
[23:02:46] jya_: and seeing the errors, I wonder on how it ever worked in the past… unless it's some of the new -Werror settings added in the configure
[23:10:57] lvmer1 (lvmer1! has joined #mythtv
[23:11:08] lvmer1 (lvmer1! has quit (Read error: Connection reset by peer)
[23:12:38] stuartm: peper03: believe the stuttering issue I had with the Gladiator DVD and a couple of others is a race, I stuck in some debugging and suddenly it's working fine, still need to do some digging before I find exactly where the problem lies
[23:12:39] peper03 (peper03! has quit (Quit: Konversation terminated!)
[23:14:12] lvmer (lvmer! has quit (Ping timeout: 256 seconds)
[23:24:32] lvmer (lvmer! has joined #mythtv
[23:30:16] lvmer (lvmer! has quit (Quit: Leaving.)
[23:34:10] petefunk_ (petefunk_!~pfunk@ has quit (Ping timeout: 255 seconds)
[23:34:17] petefunk (petefunk!~pfunk@ has joined #mythtv
[23:34:58] pheld (pheld! has quit (Quit: Leaving.)
[23:35:33] danielk22: jya_: I can look at it after bedtime, about 3 hours from now.
[23:35:47] jya_: no problem...
[23:37:47] danielk22: The general problem here is that there is something that requires certain posix headers that aren't being included. I usually just google the man page + problem platform name..
[23:46:38] petefunk (petefunk!~pfunk@ has quit (Ping timeout: 244 seconds)
[23:47:04] Sharky-Sleep is now known as Sharky112065
[23:47:58] jya_: danielk22: but why would it not build for just that branch?
[23:48:26] danielk22: With the mythmiscutil.h it is missing "#include <sys/time.h>" for "MBASE_PUBLIC bool getUptime(time_t &uptime);", but adding that include would be a bad fix. We shouldn't be using time_t in a header that is visible to non-unix platforms.
[23:50:25] danielk22: jya_: System headers often include other system headers and so it will compile on some systems, but not others. Including the header in which a type or function is declared that you use is the only thing that will result in code that compiles everywhere.
[23:51:11] jya_: sys/time.h isn't available on every platform though
[23:51:33] jya_: on linux it doesn't exist I believe, only BSD (so mac)
[23:51:34] danielk22: right, hence including it there would be a bad fix.
[23:51:55] jya_: i think configure check for sys/time.h and genere a #define for it
[23:51:58] danielk22: I exists on Linux
[23:52:34] jya_: could always include mythconfig.h and do #if blah
[23:52:34] jya_: $ ls -l /usr/include/sys/time.h
[23:52:35] jya_: ls: cannot access /usr/include/sys/time.h: No such file or directory
[23:53:12] jya_: that's on a ubuntu 12.04 box (I know it doesn't exist because my first fix was to do #include sys/time.h and it failed on linux (it fixed it on my mac)
[23:53:25] jya_: i'm still puzzled on how myth archive ever compiled
[23:53:31] danielk22: I have it on an ubuntu 12.04 system..
[23:53:54] jya_: same with the fix I pushed last night where I shuffled the #include around...
[23:54:08] jya_: why it worked before, and not now… mystery
[23:54:58] danielk22: heh, yeah. I'm sure you could solve it if you spend a enough time on it. Not worth it.
[23:55:37] zombor (zombor!~zombor__@kohana/developer/zombor) has joined #mythtv
[23:58:33] sl1ce (sl1ce! has quit (Quit: Konversation terminated!)
[23:59:41] knightr: danielk22, stichnot unfortunately, unless I'm not understanding something the way the init_tr() stuff is done is overkill and actually causes translation problems (the way the lookup is done there is no way to differenciate between a storage group and a recording group for example). The fact that it's in programinfo.cpp also imakes it diffiicult to call everywher it should be used... When I noticed the problem we were in freeze otherwise I w
[23:59:41] knightr: ould have modified it...

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