:: #mythtv

Daily chat history

Current users (84):

aloril, andreax, Anduin, Anssi, anykey_, beata, Beirdo, bernard_, brfransen, Chutt, clever, coling, Cougar, dagar, danielk22, Dave123-road, dblain_, dekarl1, dlblog, eharris, elvum, flexy, foobum_, foxbuntu, ghoti_, Gibby, gregL, GreyFoxx, hads, hobiga, holomntn, iamlindoro, ikonia, J-e-f-f-A, j-rod|afk, jams, jannau, jarle, jcarlos, JEDIDIAH__, joe__, jpabq, jpabq-, jstenback, justpaul, kc, ke^, kisak, knightr, kormoc, Kunalagon, kurre, laga, leprechau, lyricnz, mag0o, markk, mike|3, mrand, MythBuild, MythLogBot, okolsi, pheld, poptix, purserj, RDV_Linux, reynaldo, rhpot1991, rooaus, skd5aner, Snow-Man, sphery, Splat1, stuarta, superm1, sutula, tgm4883, ThisNewGuy, tomimo, tris, weta, xris, ybot, _charly_
Saturday, February 12th, 2011, 00:01 UTC
[00:01:40] purserj_ is now known as purserj
[00:02:17] lyricnz (lyricnz! has joined #mythtv
[00:02:50] lyricnz: why does mythfe use such a crazy amount of CPU on mac? surely not just the rendering? (since same mac can play 3d games etc)
[00:03:28] wagnerrp: because video decoding takes a lot of power?
[00:03:33] GreyFoxx: video rendering and playback has little to nothing to do with 3d, + wrong channel :)
[00:03:35] wagnerrp: by the way, youre on the wrong channel
[00:03:46] Kunalagon (Kunalagon!~Kunalagon@ has quit (Quit: Leaving.)
[00:04:04] lyricnz: not playing videos, using the UI. it's a developery question, if there's a developery reason, and could be fixed.
[00:04:18] ** lyricnz is a developer, of course. **
[00:04:20] wagnerrp: probably alpha pulse stuff
[00:24:31] vontrapp (vontrapp!~vontrapp@ has quit (Quit: leaving)
[00:29:42] jya (jya!~jya@ has joined #mythtv
[00:29:42] jya (jya!~jya@ has quit (Changing host)
[00:29:42] jya (jya!~jya@mythtv/developer/jya) has joined #mythtv
[00:36:21] markk: lyricnz: I've been looking at the theme/UI load issue in recent days. The quick and easy solution is to grep libs/libmythui/mythmainwindow.cpp for 70 and drop that to 30 – 70fps is way too high
[00:38:04] markk: skd5aner: re MythFEXML – next step is add a simple html remote control to the frontend (should take about 20 minutes!). I've been disappointed with the responsiveness of sending actions through the http interface though – I'm not so sure how useful it will be.
[00:40:56] markk: as far as state/status goes – my slightly bigger plan is to implement the entire upnp mediarenderer 'stack' – and that requires full state monitoring and eventing. My preference would be to have the http 'actions' match the control socket versions – and ultimately some consistency between http interface, control socket and upnp media renderer...
[00:41:25] markk: skd5aner: re non-livetv – yes, that effectively refers to anything that isn't livetv
[00:54:55] sphery: markk: I say commit the 30Hz UI update to master and see who complains... If no one, then we can push it back to -fixes :)
[01:10:37] dekarl1 (dekarl1! has joined #mythtv
[01:11:01] dekarl (dekarl! has quit (Ping timeout: 240 seconds)
[01:22:24] markk: sphery: I'm intending to do a little more. I'm going to key it off the screen rate – 24/25/29.97 for displays at those rates – 25/30 for 50/60 hz displays. then I'm going to talk to stuartm about updating libmythui so alpha (and animations) are time based rather than refresh based
[01:23:20] markk: the obvious problem at the moment is that if we drop the rate – the alpha pulses and screen fades slow down
[01:25:41] sphery: markk: ah, yeah... he mentioned some stuff about time-based at , referring to
[01:29:34] davide_ (davide_!~david@mythtv/developer/gigem) has joined #mythtv
[01:32:09] markk: sphery: I new I'd seen that discussed before :) anyway – I think it's time to bite the bullet and get this stuff sorted. If you want a demo of how broken the current code can be – try running something like graphite with the opengl painter and without opengl sync to vblank enabled. it quite (un)happily chugs away at 70fps and hogs 100%cpu
[01:33:42] gigem_ (gigem_!~david@mythtv/developer/gigem) has quit (Ping timeout: 272 seconds)
[01:37:11] sphery: markk: yeah, I see the 100% in Watch Recordings due to the pulse, would be nice to come up with a plan and fix any animations/themes/whatever that falls out
[01:37:26] kormoc is now known as kormoc_afk
[01:38:53] jya (jya!~jya@mythtv/developer/jya) has quit (Quit: jya)
[02:10:44] ghoti_ (ghoti_! has quit (Quit: Lost terminal)
[02:32:33] kisak (kisak! has joined #mythtv
[02:36:59] kisak: is there any point in asking about a bug in 0.24-fixes which didn't get a response in mythtv-users?
[02:41:53] kisak: sometimes I get dud scheduled shows, it appears the file is not spawned, here's the relevent backend snippet
[02:43:04] kisak: it seems a TVRec(4): rec->GetPathname(): '/mnt/recordings#/6624_20110211210000.mpg' line is missing
[02:45:49] danielk22: Getting time based animations right is non-trivial.. Fixing the rate at 24–30 fps is much easier. Painted cell animations traditionally run at about 14 fps, so you don't need a high frame rate for good animations.
[02:49:34] danielk22: The difficulty of time-based animations is captured by the animation for a bouncing ball. If you drop the frame where the ball touches the ground it no longer looks like it bounces the floor. Instead it unnaturally pauses in mid-air and then changes direction.
[02:50:54] kormoc_afk is now known as kormoc
[02:52:13] danielk22: Targeting 25 fps and then running the actual animation at somewhere between 24 and 30 fps depending on the refresh rate would probably look best. (i.e. trying to get each frame of the animation displayed an equal amount of time).
[02:57:32] danielk22: Anyway, I'm not implementing it so don't take my ramblings all too seriously. ;]
[03:10:06] markk: danielk22: I think it's safe to say that the current situation is not ideal – and I suspect we can cross the bouncing ball bridge when we get there:)
[03:10:58] markk: banging my own drum to a certain extent – but the one thing that people commented on time and again with the new OSD was the smoothness of the OSD fade... which is time based
[03:35:05] danielk22: heh, yeah i'm probably making too big a deal of the issues. i had ken perlin as a thesis advisor (the tron & perlin noise guy).
[03:41:26] Dave123 (Dave123! has quit (Ping timeout: 250 seconds)
[03:42:16] Dave123-road (Dave123-road! has quit (Ping timeout: 272 seconds)
[03:43:26] Dave123 (Dave123! has joined #mythtv
[03:45:07] Dave123-road (Dave123-road! has joined #mythtv
[03:57:51] markk: okolsi: if I was premature in closing that ticket, just shout.
[04:09:13] GreyFoxx (GreyFoxx!greg@mythtv/developer/GreyFoxx) has quit (Ping timeout: 240 seconds)
[04:12:23] GreyFoxx (GreyFoxx! has joined #mythtv
[04:31:17] GreyFoxx (GreyFoxx! has quit (Ping timeout: 240 seconds)
[04:31:23] GreyFoxx (GreyFoxx! has joined #mythtv
[04:35:25] GreyFoxx (GreyFoxx! has quit (Changing host)
[04:35:25] GreyFoxx (GreyFoxx!~greg@mythtv/developer/GreyFoxx) has joined #mythtv
[04:38:45] Beirdo^2 (Beirdo^2!~gjhurlbu@ has joined #mythtv
[04:38:45] Beirdo^2 (Beirdo^2!~gjhurlbu@mythtv/developer/beirdo) has joined #mythtv
[04:38:45] Beirdo^2 (Beirdo^2!~gjhurlbu@ has quit (Changing host)
[04:43:08] elmojo: markk: I made the assumption that interactiveTV in mythplayer.cpp would be set if playing back MHEG and NULL otherwise – is this you understanding? I didn't have any MHEG material to test with
[04:47:44] markk: elmojo: I'm not sure that's right – I think if Interactive TV is enabled in OSD settings, then an MHEG object is created regardless.
[04:48:42] iamlindoro: [23411]
[04:48:42] MythLogBot: SVN 23411: (branch master)
[04:48:53] iamlindoro: markk, ^^
[04:51:49] elmojo: markk: ok, I'll need to figure out a better way to detect MHEG again before the complaints start
[04:59:06] elmojo: markk: itvVisible should do the trick – does MHEG have a video track (I assume it does)?
[05:06:43] Beirdo: elmojo: just pushed the duration stuff
[05:24:15] elmojo: Beirdo: I'm still not sure about using the recordinginfo start and end times – wonder how safe it is
[05:24:30] markk: iamlindoro: I thought the person in that ticket was talking about dvb?
[05:25:37] nutron-home (nutron-home! has joined #mythtv
[05:25:43] elmojo: Beirdo: still might be best just to use ic->duration if commflag hasn't been run yet – I dunno anymore – good work and thanks for putting that together
[05:25:52] markk: elmojo: I don;t think itvvisible is going to help
[05:25:53] Beirdo: no problem
[05:26:13] Beirdo: feel free to tweak the playback hook if you want, of course :)
[05:26:24] Beirdo: or whatever works :)
[05:26:56] elmojo: markk: yeah, I realize that now – would be nice if noVideoTracks covered MHEG
[05:27:37] elmojo: seems like MHEG will be a data stream or possibly a private stream – any idea if MHEG will result in noVideoTracks?
[05:28:13] elmojo: or is MHEG in addition to a video stream?
[05:28:29] elmojo: I'm still not sure that people saw duration/position issues with MHEG
[05:33:19] elmojo: does anyone have an MHEG sample they could provide for me?
[06:08:05] natanojl (natanojl! has joined #mythtv
[06:21:11] ghoti (ghoti! has joined #mythtv
[06:30:33] nutron-home (nutron-home! has quit (Ping timeout: 260 seconds)
[06:39:56] DJDan (DJDan! has quit (Remote host closed the connection)
[07:57:29] ghoti_ (ghoti_! has joined #mythtv
[07:58:54] ghoti (ghoti! has quit (Ping timeout: 246 seconds)
[08:18:17] Kunalagon (Kunalagon!~Kunalagon@ has joined #mythtv
[08:21:57] jmartens (jmartens! has joined #mythtv
[08:28:05] Beirdo: mailing lists back up, BTW
[08:28:39] Beirdo: although, if your email is greylisted, or on AOL, Yahoo or AT&T, expect slow service for a while
[08:31:03] xris: guess I should add a news post about that
[08:34:29] Beirdo: couldn't hurt
[08:49:02] stoffel (stoffel! has joined #mythtv
[09:00:18] Goga777 (Goga777! has joined #mythtv
[09:36:14] SteveGoodey (SteveGoodey! has joined #mythtv
[10:03:32] stoffel (stoffel! has quit (Ping timeout: 255 seconds)
[10:07:27] andreax (andreax! has joined #mythtv
[10:13:17] dekarl1: danielk22: I like to pick nits so fwiw, cell based movies usually got 12fps (each used twice to get 24fps, each shown three times to get 72Hz in cinemas ;) with 12*4 being close to 50Hz (speed it up) and 12*5 being 60Hz that's not the worst framerate to choose. But 12Hz might work as rate of control points that get interpolated or so
[11:05:02] mike|2 (mike|2! has quit (Remote host closed the connection)
[11:05:54] mike|3 (mike|3! has joined #mythtv
[11:33:26] stuartm: heh, MPEG are now talking about developing a third codec for internet use, one which will be royalty free but not controlled by Google
[11:34:35] stuartm: elmojo: MHEG will result in 'noVideoTracks' and kDecodeAudio (resulting from 'noVideoTracks') means that we never decode the MHEG
[11:36:25] stuartm: MHEG has no video track, it can appear as private data in streams which already have video, but mheg has no ownership over the video and video isn't required by mheg, not even audio is required – there are channels with mheg only information services
[11:39:32] stuartm: maybe worth mentioning that the MHEG engine can change channels, so an mheg application which for example talks about live coverage of a sports event can have and 'watch match 1' and 'watch match 2' buttons which actually change the channel to one which carries the video stream
[12:22:39] Kunalagon (Kunalagon!~Kunalagon@ has quit (Remote host closed the connection)
[12:25:00] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[12:25:54] Kunalagon (Kunalagon!~Kunalagon@ has joined #mythtv
[12:29:37] gigem (gigem! has joined #mythtv
[12:29:37] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[12:29:37] gigem (gigem! has quit (Changing host)
[12:33:17] davide_ (davide_!~david@mythtv/developer/gigem) has quit (Ping timeout: 240 seconds)
[12:51:42] jmartens1 (jmartens1! has joined #mythtv
[12:52:38] jmartens (jmartens! has quit (Ping timeout: 260 seconds)
[12:56:13] stoffel (stoffel! has joined #mythtv
[12:57:12] jannau (jannau! has quit (Ping timeout: 245 seconds)
[12:58:00] jannau (jannau! has joined #mythtv
[12:58:45] danielk22: dekarl1: Makes sense. My brain did return both 12 and 14 and I didn't bother to consult google ( 12 just felt too low :P )
[13:08:45] Kunalagon (Kunalagon!~Kunalagon@ has quit (Quit: Leaving.)
[13:08:53] Kunalagon (Kunalagon!~Kunalagon@ has joined #mythtv
[13:27:51] stuartm: markk: if you want to make changes to animations and the like then I've no objections, that bit of code pre-dates my involvement with mythui and I've never really grasped the reasoning behind the current 70hz timer
[13:29:14] stuartm: markk: Chutt might be the guy to ask about that stuff, he not only wrote it but he has some experience of UI animation from work IIRC
[13:30:07] stuartm: so long as it doesn't result in significant anomalies such as drop frames disrupting the animation then I'm fine with any changes
[13:33:31] stuartm: the main issue I can see will be the fact that many of the existing image animations don't use a huge number of frames (in total), so any frame drops are going to be more noticeable – this is where it might make sense to allow the themer to decide whether timing or displaying every frame is more important to their animation with an attribute/element in the markup
[13:34:50] stuartm: clearly that's not such a problem for effects such as alpha-pulse, movement or colour cycling, it's more something specific to the image animations
[13:40:48] stoffel (stoffel! has quit (Read error: Operation timed out)
[15:05:38] Chutt: i just picked it randomly because i didn't want to bother with time-based for the first mythui implementation
[15:09:30] Goga777 (Goga777! has quit (Ping timeout: 255 seconds)
[15:10:14] Goga777 (Goga777! has joined #mythtv
[16:07:08] knightr: xris, Beirdo, Is it possible that the wiki got downgraded to an older backup (MX for is which is the same host as the wiki so could this be related to the server move)?
[16:07:50] knightr: The wiki translation page ( lost a few updates since the last time I checked it...
[16:08:20] stuartm: ffs, it's the middle of the day, safe time to restart the backend right? No, I've just screwed up the recording of a film I wanted to archive
[16:09:47] stuartm: guess I'll wait for the blu-ray to turn up in the bargin bin
[16:20:41] BigBeerJR (BigBeerJR! has joined #mythtv
[16:22:19] stuartm: markk, elmojo: livetv does seem faster and more reliable, so nice work, recording playback start feels much faster
[16:25:28] stuartm: markk: I can cause a lockup on playback start by repeatedly pressing the play button, it actually seems to apply to any keypress before video appears on screen e.g. volume up/down but the PLAY/SELECT case is easiest to reproduce as you don't need to move your thumb/finger
[16:44:55] kenni: stuartm, (markk): I just got the same lockup as you mention, but on 0.24-fixes. Some recent update in -fixes has apparently removed the "Please wait..." pop-up, so clicking play once doesn't seem to do anything at first – therefore you click again, which lockups the frontend.
[16:46:48] markk: stuartm, kenni: can you run in gdb and get a bt – should be a simple enough fix (hopefully)
[16:50:45] jmartens1 (jmartens1! has quit (Ping timeout: 255 seconds)
[16:52:45] jmartens (jmartens! has joined #mythtv
[17:03:35] Goga777 (Goga777! has quit (Quit: Leaving)
[17:05:08] kenni: markk:
[17:06:19] kenni: that's on v0.24-162-g0ddc3f2
[17:09:04] BigBeerJR (BigBeerJR! has left #mythtv ("Konversation terminated!")
[17:21:02] Goga777 (Goga777! has joined #mythtv
[17:21:20] stuartm: yeah my backtrace is much the same, it's the player write lock
[17:22:33] stuartm: markk: sorry for no posting a backtrace earlier, I had to take a phone call
[17:29:26] gigem_ (gigem_! has joined #mythtv
[17:29:26] gigem_ (gigem_! has quit (Changing host)
[17:29:26] gigem_ (gigem_!~david@mythtv/developer/gigem) has joined #mythtv
[17:30:35] stuartm:
[17:35:29] markk: stuartm, kenni: should just be a case of removing the processevents call in tv::handlestatechange – I'd dig now but it's 1.30 in the morning after 1 or 2 soft drinks
[17:37:44] stuartm: markk: I'll give that a go and let you know
[17:41:18] gregL (gregL! has joined #mythtv
[17:44:48] stuartm: markk: that does the trick
[18:25:25] SteveGoodey (SteveGoodey! has joined #mythtv
[18:45:55] stoffel (stoffel! has joined #mythtv
[18:52:13] jstenback (jstenback! has quit (Read error: Connection reset by peer)
[19:01:30] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[19:02:15] jstenback (jstenback! has joined #mythtv
[19:02:18] davide (davide! has quit (Remote host closed the connection)
[19:03:13] SteveGoodey (SteveGoodey! has joined #mythtv
[19:12:04] Dave123 (Dave123! has quit (Quit: Leaving)
[19:14:11] gigem (gigem! has joined #mythtv
[19:14:11] gigem (gigem! has quit (Changing host)
[19:14:11] gigem (gigem!~gigem@mythtv/developer/gigem) has joined #mythtv
[19:20:14] jmartens (jmartens! has quit (Quit: Leaving.)
[19:37:10] Dave123 (Dave123! has joined #mythtv
[19:38:51] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[19:39:46] Dave123 (Dave123! has quit (Remote host closed the connection)
[19:40:17] skd5aner: markk: thanks for the info on the http/upnp control stuff. I use a nevo remote, and some of their remotes (Nevo S70 for example) can do 2 way control via http as well as are compliant with the UPNP remote stuff. So, would be excited to be able to fully leverage that kind of capability with myth... look forward to any progress you make :)
[19:40:48] SteveGoodey (SteveGoodey! has joined #mythtv
[19:44:28] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[19:49:23] SteveGoodey (SteveGoodey! has joined #mythtv
[20:08:06] stoffel (stoffel! has quit (Remote host closed the connection)
[20:31:17] sphery: kenni: FWIW, I don't think anything removed the Please Wait screen--I think it's just a matter of the timing changing drastically and the fact that that screen was finicky before because of how we're doing (and disabling) UI updates--it only appeared for some users depending on timing. I'm pretty sure you (maybe everyone) just switched to the "doesn't appear" side.
[20:32:13] SteveGoodey (SteveGoodey! has quit (Remote host closed the connection)
[20:47:48] sphery: stuarta: I just moved #9566 to EIT. I'll leave it to you--and your vastly-superior knowledge of EIT to decide how to handle it. I think it's half misconfiguration (that we could likely detect) and half duplicate of #8251.
[20:52:57] sphery: oh, btw, my comment on the ticket explains the details better (and refs the user reply that provided the info)
[20:59:03] danielk22: sphery: In the US standards the EIT should not be encrypted even if the channel is encrypted. AFAIK in Europe the EIT may be in a secret encoding even if the channel is FTA, so whether the channel is encrypted isn't a great guide as to whether the EIT is. And of course you shouldn't have encrypted channels in your lineup that you don't have a decoder card for..
[21:01:44] kenni: sphery: Ok, thanks for the info. I wasn't aware that some people didn't see the Please Wait screen. It's a bit sad though, as not showing the screen introduces a usability issue – on my Ion frontend, it still takes 2.5–3.0 seconds for the recording to show up, so you'll end up clicking the play button 2 or 3 times until "something happens".
[21:05:56] sphery: danielk22: Ah, ok, so it's a misconfiguration we probably can't detect--so if the other is a dup of #8251, we can probably close the ticket. Thanks for the extra info.
[21:07:04] sphery: kenni: yeah, it's something that will eventually get fixed up, but it hasn't been the highest-priority issue. I think a lot of Mark's changes to the player and threading are going to make it easier to "do it right."
[21:10:55] stuartm: the 'encoding' (really Huffman compression) of EIT for some services in Europe is in many respects odd, e.g. the decision to huffman encode Freesat EIT in the UK is probably just to frustrate Sky customers who try to manually tune Freesat-only channels (of which there are almost none) – Freesat (FTA) is directly competing against Sky (Subscription) but it's motivated mostly by a desire among broadcasters to protest Sky's growing domination of
[21:10:57] stuartm: the broadcast world
[21:13:17] stuartm: and the fact that they use Huffman (aka compression) vs real encryption reflects the fact that the BBC et al are legally and morally obliged to provide their services freely – so weak and easily circumvented compression can be defended more easily than true encryption
[21:42:35] xris: knightr: you are likely correct. we forgot to sync the db...
[21:44:20] natanojl (natanojl! has quit (Ping timeout: 250 seconds)
[21:59:43] xris: knightr: ok, wiki fixed.
[22:03:32] knightr: xris, Thank you!
[22:04:03] xris: hopefully that was the last piece
[22:04:10] xris: would very much like to get this project overwith
[22:04:19] xris: especially with the new boxes from Captain_Murdoch showing up eventually
[22:04:46] knightr: xris, that server is temporary?
[22:06:26] stuartm_ (stuartm_! has joined #mythtv
[22:06:26] stuartm_ (stuartm_! has quit (Changing host)
[22:06:26] stuartm_ (stuartm_!~stuartm@mythtv/developer/stuartm) has joined #mythtv
[22:06:27] xris: yeah, it's a rackspace cloud virt on loan from schedules direct
[22:06:34] xris: so we can completely reformat our box at osu
[22:06:50] stuartm (stuartm!~stuartm@mythtv/developer/stuartm) has quit (Ping timeout: 240 seconds)
[22:07:38] jpabq-: elmojo, I am running trunk from Feb 5, and I just tried letting LiveTV transition from one show to the next using a HD-PVR --- took about 2 seconds. Did you ever figure out why it is taking 9 seconds for you?
[22:08:11] knightr: ah, ok... thanks for the info!
[22:09:12] stuartm_ is now known as stuartm
[22:24:13] Beirdo: jpabq-: I think that BBC patch stuff slows down commflag on my HDPVR recordings... a lot. Not 100% sure that it's the cause, but it seems to coincide
[22:26:36] Beirdo: not sure anything can be done about it though
[22:28:40] jpabq-: Beirdo, I am not really surprised. With BBC stuff, a NAL can be too big to fit in a single "packet", and it is hard to figure out the SEI NAL size without finding the *next* NAL first --- so the BBC "fix" requires a LOT more processing.
[22:28:50] Beirdo: ahhh
[22:28:53] Beirdo: gotcha
[22:29:20] jpabq-: It is possible that some optimization could be done, though.... I will have to look at it some more.
[22:29:30] Beirdo: well, kinda disappointing to have it so much slower, but if that's how it is going to be so other stuff works, I'll live with it :)
[22:31:23] jpabq-: If it is dramatic, we *could* go with a system where it behaves different for the HD-PVR than for other devices. We already have a "flag" which determines if I frames are counted as keyframes. We could add another "flag" which indicates if SEI NALs are important, and short circuit if they are not — but it would complicate the code a fair amount.
[22:32:06] elmojo: jpabq-: nope, never dug into it – and it varied from ~2.5s to ~9.0s
[22:32:09] Beirdo: well, I guess if we have to... Complicating the code's not often a choice we'd want to take
[22:32:34] jpabq-: elmojo, Ah. I did not realize it varied. I just tried it once.
[22:33:54] elmojo: jpabq-: it seemed to get a little longer each time for some odd reason – maybe coincidence
[22:35:04] jpabq-: I did notice that telling the HD-PVR to *stop* encoding "recording", almost always takes 2 seconds. I don't know why it takes that long, though. Maybe it is flushing buffers?
[22:35:34] flexy (flexy!~flexy@ has joined #mythtv
[22:35:42] jpabq-: Not that that is happening on a LiveTV program change.
[22:36:22] flexy: markk: Are you online?
[22:36:32] elmojo: stuartm: thanks for the MHEG info – nice to know I might just need to key off of noVideoTracks – I'm going out on a limb and assuming that the MHEG problems people saw didn't have a video track to use for duration and position so it was off for that scenario
[22:37:25] Beirdo: DeviceReadBuffer is used in the recording path, correct?
[22:37:33] elmojo: jpabq-: if you have any debug code or want a log for the transitions that take a long time then let me know
[22:37:58] elmojo: also, was the 2 seconds for a 720p or 1080i channel?
[22:38:11] jpabq-: elmojo, I don't even know what code-path myth takes for that.
[22:38:15] jpabq-: 720p
[22:38:16] iamlindoro: markk, "[FFmpeg-devel] Another possible bug in dvbsub.c" may be the right one this time
[22:38:18] elmojo: from memory it seemed 720p was faster for some reason
[22:38:33] stuartm: elmojo: I noticed that audio/mheg radio channels are presently broken in trunk, is that what you're working on fixing?
[22:38:42] iamlindoro: markk, "The problem with current dvbsub encoded with ffmpeg is that the subtitles are not remove from display as expected (they remain displayed for a much longer period, unless some other sub replaces them). This was tested with VLC, ffplay, and also with other hardware devices (set-top-boxes)."
[22:38:56] elmojo: stuartm: you referring to duration/position for the OSD?
[22:39:10] elmojo: it should be fixed now
[22:39:30] stuartm: elmojo: no, playback, it complains about there being no video and gives up after a few seconds
[22:39:54] elmojo: stuartm: any idea when that started?
[22:40:49] stuartm: Player(8): Waited 100ms for video buffers AAAAAAAAAAAAAAAAA
[22:40:58] stuartm: elmojo: last week or two
[22:41:24] elmojo: stuartm: you running master?
[22:41:25] stuartm: actually, I'm not too sure of that
[22:41:29] stuartm: elmojo: yeah
[22:41:58] stuartm: elmojo: well, less than 24 hours old
[22:42:09] flexy: I have made a bug report some time ago concerning .24-fixes. After the report, I eventually upgraded to trunk/head/whateveritscallednow and the problem was happening a lot less frequently. Now I'm asked to confirm if it still happens with the latest updates to .24-fixes. Is there a way to downgrade the system to confirm this?
[22:42:34] stuartm: elmojo: I'd have to downgrade to check when it broke, I don't record radio channels much if at all
[22:42:53] elmojo: stuartm: ok, the stuff I'm working on is cosmetic in nature and shouldn't have an affect on playback unless I'm confused which is always a possibility
[22:43:28] flexy: I had 27420 version, I upgraded to v0.25pre-1070-g9590973...
[22:44:22] stuartm: elmojo: ok, I wasn't assigning blame of any sort, I thought you might have been aware of it and were working on a fix – I haven't been following IRC so closely this past week and when you mentioned mheg I jumped to conclusions
[22:45:11] elmojo: stuartm: the -fixes users haven't reported any issues on very recent builds so it might just be master that's go the issue
[22:47:06] stuartm: elmojo: I'll do some digging
[22:47:15] sphery: flexy: Checking with most-current trunk is probably fine--he probably didn't realize you were on trunk, now. Just make sure to specify in the reply what version you used for testing. And, no--other than restoring a pre-upgrade database backup--there's no supported downgrade path.
[22:55:15] elmojo: jpabq-: I'd be interested if you see a difference between 720p and 1080i LiveTV transitions
[22:55:30] jpabq-: elmojo, I will give a try here in a bit.
[22:57:10] jpabq-: There are times when I wish I had faster CPUs — like when compiling from scratch.
[22:58:21] elmojo: make -jX
[22:59:07] elmojo: just mentioning it because I forget to use it sometimes
[23:02:06] jpabq-: elmojo, 5 seconds for 1080i just now
[23:02:16] Goga777 (Goga777! has quit (Ping timeout: 240 seconds)
[23:05:48] jpabq-: Looks like the delay is in finding the "Payload start".
[23:18:35] elmojo: jpabq-: cool
[23:34:08] flexy: sphery: OK, I waited for couple of months for the fixup, then WAF drop out came too strong, had to do something.... I "upgraded" back to trunk/head and the problem is less frequent. But to the user point of view, it still happens. What I've been told is that these symptoms are something of a "catch all errors"
[23:34:42] flexy: so I don't know if the remaining same symptoms are still the same "bug" or another
[23:35:13] flexy: in any case, it's less frequent now after upgrading to head/trunk
[23:35:48] flexy:
[23:36:01] flexy: if knowing the bug report in question has any relevance...
[23:44:32] sphery: flexy: You need a much newer version to test the fixes. They went in (to both 0.24-fixes and trunk) as recently as Wednesday of this week and v0.25pre-1070-g9590973 is from Jan 31. Please upgrade to a version from Thursday or after and try again. Thanks.

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