MythLogBot@irc.freenode.net :: #mythtv

Daily chat history

Current users (61):

MythBuild, MythLogBot, aloril, Anssi, blahdodo, brfransen, ChanServ, clever, davic, dym, eharris, ElmerFudd, enyc, frobnic, gary_buhrmaster, ghoti, gigem, GreyFoxx, hampton, Hydr0p0nx, Hydroponx, ijc, jheizer, jpabq, jpharvey, jya, kalamaja_, knowledgejunkie, libsci, mad_enz, Maliuta_, markspieth, MitchCapper, mkbloke, MythNotifyBot_, nephyrin, ooshlablu, Panic, poptix, pppingme, ramshadow, rhpot1991, sphery, stuarta, stuartm, taylorr, toddejohnson, tonsofpcs, tris, Warped, xris, zbot, _charly_, RokLobsta, tgm4883, peper03, kwizart, dragonian, markspieth2, Cougar, lomion0815
Thursday, February 7th, 2019, 01:13 UTC
[01:13:26] Cullran (Cullran!~Cullran@136.0.0.107) has joined #mythtv
[01:13:27] Cullran (Cullran!~Cullran@136.0.0.107) has left #mythtv ()
[01:17:23] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has quit (Quit: Yaaic - Yet another Android IRC client - http://www.yaaic.org)
[01:17:50] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[01:17:50] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth
[03:08:50] bailecoffin (bailecoffin!~bailecoff@103.25.59.84) has joined #mythtv
[03:08:51] bailecoffin (bailecoffin!~bailecoff@103.25.59.84) has left #mythtv ()
[03:39:06] Strozill (Strozill!~Strozill@103.25.59.92) has joined #mythtv
[03:39:08] Strozill (Strozill!~Strozill@103.25.59.92) has left #mythtv ()
[04:16:46] gigem: peterbennett: I hope you've got a platinum patch tomorrow. Golden was unusable for me tonight! :) Seriously, https://pastebin.com/44B0wP7t is a log from simply starting playback without any jumps. The code seems to get stuck continuously dropping audio and then video essentially creating it's own fast-forward mode. It would frequently do this after forward jumps too. That's why it was unusable.
[06:45:51] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has quit (Read error: Connection reset by peer)
[06:46:00] markspieth (markspieth!~yaaic@202.169.118.74) has joined #mythtv
[06:46:04] markspieth (markspieth!~yaaic@202.169.118.74) has quit (Changing host)
[06:46:04] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[06:46:04] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth
[06:56:34] Tobbe5178 (Tobbe5178!~asdf@2001:2002:51eb:d24e:41ff:3834:c5e2:c8f1) has joined #mythtv
[07:32:49] Steve-Goodey (Steve-Goodey!~steve@2a00:23c5:7da3:4501:7a84:3cff:fedf:a99) has joined #mythtv
[07:32:50] Mode for #mythtv by ChanServ!ChanServ@services. : +v Steve-Goodey
[07:37:32] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has quit (Ping timeout: 240 seconds)
[07:42:32] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[07:42:32] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth
[07:48:46] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has joined #mythtv
[07:59:04] markk_: gigem: do you have a sample with ass subtitles that are being hidden?
[08:05:46] peterbennett (peterbennett!~pi@mythtv/developer/peterbennett) has quit (Ping timeout: 268 seconds)
[08:10:54] markspieth3 (markspieth3!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[08:10:54] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth3
[08:14:21] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has quit (Ping timeout: 244 seconds)
[08:15:36] peterbennett (peterbennett!~pi@2601:183:101:1dd4:e6c8:b90c:eb45:8cbe) has joined #mythtv
[08:15:36] peterbennett (peterbennett!~pi@2601:183:101:1dd4:e6c8:b90c:eb45:8cbe) has quit (Changing host)
[08:15:36] peterbennett (peterbennett!~pi@mythtv/developer/peterbennett) has joined #mythtv
[08:15:36] Mode for #mythtv by ChanServ!ChanServ@services. : +v peterbennett
[08:46:59] willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has joined #mythtv
[08:49:05] nephyrin (nephyrin!~neph@2601:600:817f:a19a:a5cf:8446:c53:57b2) has quit (Ping timeout: 250 seconds)
[08:51:47] nephyrin (nephyrin!~neph@2601:600:817f:a19a:a5cf:8446:c53:57b2) has joined #mythtv
[08:57:19] nephyrin (nephyrin!~neph@2601:600:817f:a19a:a5cf:8446:c53:57b2) has quit (Ping timeout: 250 seconds)
[09:01:48] nephyrin (nephyrin!~neph@2601:600:817f:a19a:a5cf:8446:c53:57b2) has joined #mythtv
[09:05:21] MythBuild (MythBuild!~MythBuild@mizar.mythtv.org) has quit (Remote host closed the connection)
[09:05:39] MythBuild (MythBuild!~MythBuild@mizar.mythtv.org) has joined #mythtv
[09:06:24] stuarta: jheizer: renamed your jessie worker to stretch
[09:11:56] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has quit (Ping timeout: 272 seconds)
[09:22:49] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has joined #mythtv
[09:27:27] MythBuild: Build 2019-render-debian-buster-64bit #23 is complete: Failure [failed test (failure)] – https://code.mythtv.org/buildbot/#builders/104/builds/23
[09:27:27] ** MythLogBot https://code.mythtv.org/trac/ticket/23 **
[09:27:39] nephyrin (nephyrin!~neph@2601:600:817f:a19a:a5cf:8446:c53:57b2) has quit (Ping timeout: 250 seconds)
[09:30:53] stuarta: weird test failures again
[09:31:45] nephyrin (nephyrin!~neph@2601:600:817f:a19a:a5cf:8446:c53:57b2) has joined #mythtv
[09:57:01] MythBuild (MythBuild!~MythBuild@mizar.mythtv.org) has quit (Remote host closed the connection)
[09:57:13] MythBuild (MythBuild!~MythBuild@mizar.mythtv.org) has joined #mythtv
[09:58:03] markspieth3 (markspieth3!~yaaic@mythtv/developer/markspieth) has quit (Ping timeout: 240 seconds)
[10:02:31] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[10:02:31] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth
[10:04:21] markk_: wasnt't me:)
[10:16:10] stuarta: markk_: nope, seems to randomly happen when there are queued up builds, and i start all 7 of the VM's (and therefore 7 builds) simultaneously on my laptop
[10:16:20] stuarta: clearly a loading issue.
[10:17:37] stuarta: i've just dropped them down to a single cpu each, to see if that helps
[10:27:34] markspieth3 (markspieth3!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[10:27:34] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth3
[10:29:43] markspieth (markspieth!~yaaic@mythtv/developer/markspieth) has quit (Ping timeout: 244 seconds)
[10:55:43] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Read error: Connection reset by peer)
[10:56:00] Steve-Goodey (Steve-Goodey!~steve@2a00:23c5:7da3:4501:7a84:3cff:fedf:a99) has quit (Quit: Konversation terminated!)
[10:59:39] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[10:59:40] Mode for #mythtv by ChanServ!ChanServ@services. : +v jpabq
[11:01:58] MythBuild: Build 2019-render-debian-buster-64bit #24 is complete: Success [build successful] – https://code.mythtv.org/buildbot/#builders/104/builds/24
[11:01:58] ** MythLogBot https://code.mythtv.org/trac/ticket/24 **
[11:43:40] markk_: did I ever mention that I hate vaapi...
[11:49:40] stuarta: :)
[11:50:03] stuarta: look on the bright side, now you can just feed the data to ffmpeg and get it to do it
[11:52:23] markk_: if only it were that easy. seeking is broken – I can stop it crashing but the ref counting is broken somewhere :(
[11:55:28] stuarta: vaapi2 that peterbennett did seems to work fine using the ffmpeg interfaces, and doesn't carry the legacy stuff
[11:58:08] markk_: yeah – but vaapi2 keeps everything internal to ffmpeg. rendering directly is a different ballgame. render branch isn't using legacy anymore.
[12:01:03] stuarta: i would have though the aim was to ensure everything as much as possible uses ffmpeg api's
[12:02:41] markk_: it's all using ffmpeg api's. but ffmpeg only does decode – it doesn't know how to put a frame on screen.
[12:03:15] stuarta: right, so it's the magic glue to get it directly rendered once ffmpeg has decoded it for us
[12:03:18] stuarta: ?
[12:10:10] markk_: display is working ok. it's just the seek code. the ffmpeg hardware decode api uses ref counted buffers/frames. we need to retain/ref a buffer  – otherwise ffmpeg tries to use it for decoding again before we've had a chance to display it. but somewhere in a seek, the frames aren't being released properly and ffmpeg thinks its run out of useable hardware surfaces to decode to.
[12:11:04] stuarta: i can see how that would be a problem
[12:15:20] jheizer: stuarta: renamed
[12:16:08] stuarta: and look, it's building too ;-)
[12:16:29] stuarta: jheizer: fyi, you'll want to clean up the old build directories, as they will contain the old name
[12:16:46] jheizer: yeah, removed old and renamed the rest
[12:16:54] stuarta: :)
[12:34:36] ** stuarta wonders if it's stuck, 34 minutes compiling core with no output **
[12:35:32] jheizer: hmm, was pushing a set of production updates to a client. Hadn't been watching it.
[12:37:26] markspieth3 (markspieth3!~yaaic@mythtv/developer/markspieth) has quit (Remote host closed the connection)
[12:37:35] stuarta: ooo output
[12:37:42] stuarta: jheizer: just started turning up
[12:37:48] stuarta: https://code.mythtv.org/buildbot/#/builders/17/builds/116
[12:37:54] jheizer: yeah, it had gone to sleep
[12:37:59] jheizer: I just kicked it back awake
[12:38:00] stuarta: doh
[12:38:24] jheizer: builder number changed
[12:39:06] stuarta: yeah it would do, basically seen as a new builder
[12:39:54] jheizer: yeah, I wasn't thinking about that. Sleep script updated.
[12:43:10] stuarta: you know there's an api you can query?
[12:44:07] jheizer: yeah
[12:44:09] jheizer: hitting it
[12:44:18] jheizer: so was passing the wrong worker id
[12:45:14] jheizer: found a way simple way to do it too
[12:45:25] jheizer: count=$(/usr/bin/curl "https://code.mythtv.org/buildbot/api/v2/worke . . . uildid" -s | grep "complete\": true" | wc -l)
[12:45:58] jheizer: Ask for a the single most recent build and make sure it is completed status. Didn't have to mess with the json directly or anything.
[12:47:09] stuarta: this might help
[12:47:10] stuarta: curl https://code.mythtv.org/buildbot/api/v2/build . . . mplete=false
[12:47:26] stuarta: get a nice simple json response
[12:47:50] stuarta: even with a "meta": { "total": 1 }
[12:48:19] jheizer: Builders one was hard became each branch is a builder so a lot more to query vs my above
[12:48:21] jheizer: IIRC
[12:51:32] stuarta: curl https://code.mythtv.org/buildbot/api/v2/worke . . . mplete=false
[12:51:36] stuarta: anything not complete
[12:51:54] stuarta: again with a meta total at the bottom
[12:53:09] jheizer: yeah same idea basically. Not sure why I didn't filter it.
[12:53:15] jheizer: Maybe didn't realize I could.
[12:53:38] jheizer: I had done it the /builders/ way first before I realized it multiple per slave
[13:00:43] stuarta: the only question is, are there any non complete build in the window before the build master triggers it?
[13:01:09] stuarta: in the ui they don't even show up as pending
[13:16:07] markspieth2: peterbennett: I didnt have the problems that gigem reported. Not too bad. Lots of skipping at x1.55. Some at x1.2. A bit jerky to recover though and at start. Will try some variations tomorrow.
[13:22:40] markspieth2 is now known as markspieth
[13:22:58] markspieth2 (markspieth2!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[13:22:58] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth2
[13:54:26] MythBuild (MythBuild!~MythBuild@mizar.mythtv.org) has quit (Remote host closed the connection)
[13:54:42] MythBuild (MythBuild!~MythBuild@mizar.mythtv.org) has joined #mythtv
[13:54:44] jheizer: stuarta: best I've been able to tell so far what I have been doing has worked.
[13:54:58] jheizer: Only thing I really need still is a good way of idle detection.
[13:55:11] jheizer: But I grew bored and never went back to it.
[14:23:32] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has quit (Ping timeout: 272 seconds)
[14:28:59] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has joined #mythtv
[14:46:15] Cougar (Cougar!~cougar@2001:1bf0:0:1101::52) has quit (Ping timeout: 252 seconds)
[14:49:08] Cougar (Cougar!~cougar@2001:1bf0:0:1101::52) has joined #mythtv
[15:06:02] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has quit (Quit: Konversation terminated!)
[15:13:09] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has joined #mythtv
[15:21:27] Cougar (Cougar!~cougar@2001:1bf0:0:1101::52) has quit (Ping timeout: 252 seconds)
[15:23:05] peterbennett: gigem: I am baffled by your experience. Was there any speedup involved? I ran it last evening for a couple of hours with no problems.
[15:31:02] gregl (gregl!~greg@cpe-24-194-253-7.nycap.res.rr.com) has quit (Remote host closed the connection)
[15:38:07] gigem: markk_: I sent you a link to a video sample.
[15:38:55] gigem: peterbennett: The problem happened with and without speed up.
[15:40:29] Steve-Goodey (Steve-Goodey!~steve@2a00:23c5:7da3:4501:7a84:3cff:fedf:a99) has joined #mythtv
[15:40:29] Mode for #mythtv by ChanServ!ChanServ@services. : +v Steve-Goodey
[15:41:07] Cougar (Cougar!~cougar@2001:1bf0:0:1101::52) has joined #mythtv
[15:44:23] gigem: peterbennett: You said yesterday that you use xrdp. How do you use it, i.e. any special options with the server, which client and options, etc.?
[15:45:24] peterbennett: gigem: I am on xubuntu, installed it from the default repository
[15:46:57] peterbennett: gigem: There is one tweak needed in the latest version
[15:48:06] peterbennett: I access xrdp with remmina
[15:48:18] peterbennett: I will send you an email with the tweaks
[16:02:21] gigem: peterbennett: Thanks. I'll check it out.
[16:03:30] peterbennett: gigem: So you started playback at normal speed and it went in a jerky speeded up way ?
[16:03:50] peterbennett: gigem: Which playback profile?
[16:04:01] gary_buhrmaster: gigem: (I am back). I could go into great depths regarding 5G, but today, it is more in the Gartner "Inflated Expectations" part of the hype curve, and for most people it will be quite some time before it will be available as an option for fixed wireline.
[16:05:46] gary_buhrmaster: gigem: And the pricing is currently in "the first hit is (close to) free" model. Get lots of customers, and then raise prices later.
[16:07:26] markk_: gigem: thanks – I see the problem – just need to fix it without losing the pause frame as well:)
[16:07:30] gary_buhrmaster: gigem: hamptom: FiOS does not support IPv6 (regardless of whether you can turn it on in some of the more recent routers). The prep for supporting it depended in VZ's plan to replace the ONT/CPE with a new box (which was in trial at real people's houses),
[16:08:29] gary_buhrmaster: gigem: hampton: but they decided not to go forward (and actually pulled the boxes out of homes). It was also pure IPTV (no QAM/CableCARD support for TV).
[16:10:57] markk_: gigem: sorted – will need to checkout master and test first
[16:10:58] gary_buhrmaster: gigem: hampton: FiOS currently has no (known to the networking community) schedules for providing direct end-user IPv6 at this time. It is actually quite the source of annoyance to many. Most everyone that cares is using an IPv6 tunnel service (in the consumer world, HE since it is "free").
[16:15:11] hampton: gary_buhrmaster: Good info, but :-(
[16:25:08] gary_buhrmaster: hampton: To be slightly fair, there are some high expenses in replacing all the various legacy actives, and (just like most people/companies) VZ is prioritizing those things they *need* to do and have the highest ROI (and the whiplash changes in direction by VZ management does not help).
[16:30:15] gary_buhrmaster: hampton: From certain "hallway" conversations, there are hints there are a few (isolated) islands in FiOS-land that could fully support IPv6, but that is simply not a viable deployment/support strategy.
[16:39:05] gary_buhrmaster: hampton: And then there is Frontier FiOS, which is an entirely different issue (they are trying to spend nothing on anything to try to avoid bankruptcy; whether that works depends on whether they can manage to refinance the upcoming debt maturities due in a few years; the market says they are failing).
[16:53:59] gigem: gary_buhrmaster: As I suspected regarding 5g and IPv6.
[16:54:02] gigem: markk_: Thanks.
[16:55:31] gigem: peterbennett: Yes, the first and only recording I tried (before reverting to an older apk) went right into the jerky playback. Skipping and/or ff/req would get out of it, but a following skip would go back to jerky maybe 25% of the time.
[17:10:33] peterbennett: gigem: maybe you can send a sample of the recording that behaved badly. I think I know what is going on but it would be good to test.
[17:11:04] markk_: is anyone with a modern intel gpu able to test the render branch. h264 playback is very messy and I'm not sure whether it is just my old board/driver.
[17:11:47] peterbennett: gigem: It seems that particular recording has audio ahead of video where mostly it is the other way around
[17:13:29] peterbennett: markk_: I have a "vainfo: Driver version: Intel i965 driver for Intel(R) Kaby Lake – 2.1.0"
[17:13:56] enyc: hrrm, was wondering if debian packaging issues been resolved ok, i have a build going to get going in an hour ish, and test it later, anyway...
[17:14:25] enyc: theres' many debian-derivatives without systemd, devuan, mx-linux, antix, ... i think they should still work fine with mythtv however.
[17:24:52] gigem: peterbennett: I forgot to mention the playback profile. It was OpenGL Normal (ffmpeg decode, kernel deint), though, this recording was 720p so no deint was involved. The recording was a Mavericks game on Fox Sports Southwest and I no longer have it. I will test tonight's Stars game on FSS and keep a sample it if it does the same thing.
[17:29:31] gary_buhrmaster (gary_buhrmaster!~gtb@2601:647:4802:4c3:222:4dff:fe51:6728) has left #mythtv ()
[17:31:15] zbot (zbot!~supybot@2601:647:4802:4c3:222:4dff:fe51:6728) has quit (Remote host closed the connection)
[17:32:12] peterbennett: gigem: Thanks. I can try playing my fox sports sample.
[17:32:16] zbot (zbot!~supybot@2601:647:4802:4c3:222:4dff:fe51:6728) has joined #mythtv
[17:34:35] gary_buhrmaster (gary_buhrmaster!~gtb@2601:647:4802:4c3:222:4dff:fe51:6728) has joined #mythtv
[17:39:21] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has quit (Ping timeout: 268 seconds)
[17:50:09] Merlin83b (Merlin83b!~Daniel@office.34sp.com) has quit (Quit: Leaving)
[17:55:31] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has joined #mythtv
[18:02:38] markk_: peterbennett: about 6 years more modern than my test machine:)
[18:05:26] jheizer: I have a bay trail and apollo lake if you need another check
[18:05:35] jheizer: though might take me a day or two.
[18:07:17] jheizer: or trail bay or something like that
[18:08:55] markk_: jheizer: the more the merrier!
[18:09:52] jheizer: VAAPI or opengl playback?
[18:11:25] markk_: VAAPI  – specifically h264.
[18:17:09] jheizer: k, caught the h264 part.
[18:18:11] jheizer: Will let you know. Have 720 from comcast and 1080i from old hdpvr recordings.
[18:18:16] markk_: jheizer: ah sorry – wasn't clear before:) yes – all vaapi related
[18:20:08] jheizer: no problem
[18:36:53] peterbennett: markk_: vaapi or vaapi2 ?
[18:43:22] dragonian: are there folks around to bounce some questions off of regarding Xrandr? I'm guessing peterbennett, maybe JYA? this is somewhat related to #13100.
[18:43:22] ** MythLogBot https://code.mythtv.org/trac/ticket/13100 **
[18:44:07] markk_: peterbennett: vaapi – I haven't touched vaapi2 (not least because ffmpeg's implementation doesn't work on my chipset  – the copy back to main memory fails)
[18:44:41] dragonian: I care less about judderfree, but I would like the fe to normally run at 1080p60 for most things and automatically switch to 4k resolution (at a resonable refresh)
[18:44:44] peterbennett: markk_: OK I will try vaapi....
[18:45:16] peterbennett: dragonian: What is the question?
[18:45:46] dragonian: what is currently implemented does work more or less at all with nvidia, for the same reason as the ticket, fractional refresh rates.
[18:46:29] dragonian: I updated the patch in that ticket to run on master, and I did confirm there does appear to be an issue with open gl
[18:48:24] dragonian: i get a blank display with opengl regardless of the resolution. vdpau works tho
[18:48:42] dragonian: for the resolutions that vdpau works with
[18:49:00] dragonian: any suggestion of where i should dig into?
[18:51:00] dragonian: is this completly the wrong approach? Does this work for anyone else? This used to work for me during the summer.. but something changed. based on what I'm seeing now. i have no clue how it did
[18:53:16] dragonian: oops: typo.. DOESN'T work with nvidia
[19:07:53] brfransen (brfransen!~brfransen@47.42.26.155) has quit (Read error: Connection reset by peer)
[19:09:32] brfransen (brfransen!~brfransen@47.42.26.155) has joined #mythtv
[19:10:53] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has quit (Ping timeout: 245 seconds)
[19:13:00] peterbennett: dragonian: I have not looked into it. I don't know
[19:14:01] peterbennett: dragonian: I suppose leaving your video at max resolution with best refresh rate does not work well?
[19:19:03] dragonian: so running the desktop at 4k is somewhat silly, and the 1080i deints don't work at 4k resolutions
[19:19:47] dragonian: i'm willing to dig in if you have any suggestions
[19:21:03] willcooke (willcooke!~willcooke@ubuntu/member/willcooke) has quit (Quit: Do your hobbies)
[19:25:46] dragonian: i think the tv is better at upscaling 1080p to 4k also
[19:32:43] peterbennett: Deinterlacer seems to work fine at 4K. What playback profile are you using?
[19:33:14] peterbennett: I just tried a 1080i video with 4K screen
[19:38:21] brfransen (brfransen!~brfransen@47.42.26.155) has quit (Quit: ZNC 1.7.0 - https://znc.in)
[19:45:52] brfransen (brfransen!~brfransen@47.42.26.155) has joined #mythtv
[19:46:21] dragonian: i can try that more.. I saw some issues when i tried that once, and realized that maybe it didn't make the most sense
[19:46:27] brfransen (brfransen!~brfransen@47.42.26.155) has quit (Client Quit)
[19:46:35] dragonian: i would have been using vdpau HQ
[19:46:55] brfransen (brfransen!~brfransen@47.42.26.155) has joined #mythtv
[19:47:25] gigem: peterbennett: FWIW, one of the big complaints from the Kodi crowd for the Shield is its upscaling from HD to 4k. They all tend to recommend displaying HD at 1080p and letting the TV upscale.
[19:48:58] dragonian: gigem: good to know.
[19:50:45] peterbennett: dragonian: the recent upgrade to ffmpeg 4.1 has VDPAU improvements, in master. Also you can try NVDEC to see if that looks better, althought it does not yet have direct gpu display.
[19:50:58] dragonian: i'm using it
[19:51:17] dragonian: been using nvdec since you put it in
[19:51:34] dragonian: i will try nvdec at 4k
[19:53:09] peterbennett: gigem: I put another patch out there and I will not promise it will be better, only hope...
[19:54:06] jheizer: On a related note to all of this. Intel + 4k tv. Do any of you ever end up with just the top left 1/4 of the image displaying over the entire screen? I assume hdmi/resolution negotiation fail, but I'm not sure what item is to blame.
[19:54:38] jheizer: Full ubuntu desktop is wrong, not just myth. Just thought maybe it was and issue someone had hit already.
[19:55:44] peterbennett: jheizer: I have not had that problem with my 4K monitor
[19:55:52] SteveGoodey (SteveGoodey!~steve@2a00:23c5:7da3:4501:7a24:afff:fe9d:c233) has joined #mythtv
[19:55:52] Mode for #mythtv by ChanServ!ChanServ@services. : +v SteveGoodey
[19:57:36] peterbennett: gigem: Your problem there seems to have been with audio way ahead of video and it never fixed itself. I could not find a video that had that.
[19:57:53] jheizer: k, thanks. Miss my old atom ion box. It works so flawlessly.
[19:58:49] dragonian: i still have one :)
[19:59:25] peterbennett: gigem: You could also try increasing the audio read ahead in the playback advanced settings.
[20:15:45] gigem: peterbennett: I've started a build with the new patch. Audio read ahead is already set to as least 1000 ms and maybe even 3000 ms.
[20:16:38] peterbennett: oh ok so that is not the cause of the problem.
[20:17:00] peterbennett: gigem: Sorry for all the false starts on this.
[20:28:44] gigem: peterbennett: No problem. If you're willing to work on it, I'm more than willing to help test it.
[20:32:52] peterbennett: gigem: TIP – If your playback goes crazy – instead of reinstalling an old apk you can just turn off avsync2 temporarily.
[20:36:32] gigem: peterbennett: K
[20:38:42] gigem: peterbennett: I can't get remmina to open a session to xrdp. It connects but then the disconnects. rdesktop works, including opengl, although it's noticeably slower than x2go.
[20:40:14] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has joined #mythtv
[20:40:39] peterbennett: gigem: Did you create an entry which stes "Remote Desktop Protocol" in Remmona?
[20:41:03] peterbennett: Remmina
[20:42:54] gigem: I haven't done any special configuration yet. Since it connects to the rdp port, I assume should know to use the rdp protocol.
[20:43:09] markk_: gigem: I pushed a fix for the subtitles with opengl. give me shout if there are any other issues.
[20:44:29] gigem: markk_: Dang! I'd just checked seconds ago and there weren't any new changes. Time to kill the build and restart. Thanks! :)
[20:44:31] peterbennett: markk_: You fixed #13402 ?
[20:44:31] ** MythLogBot https://code.mythtv.org/trac/ticket/13402 **
[20:45:18] markk_: peterbennett: apparently so:)
[20:45:49] peterbennett: I did not even look at it yet
[20:46:18] peterbennett: markk_: Aboit to test the vaapi
[20:48:44] peterbennett: markk_: Anything in particular I am looking for? It seems OK.
[20:49:33] markk_: peterbennett: vaapi h264 looks ok?
[20:49:39] peterbennett: markk_: CPUs are around 20% each
[20:49:54] peterbennett: markk_: Looks fine
[20:50:00] peterbennett: this is at 720p
[20:50:07] peterbennett: I can try a 1080p
[20:50:12] gigem: peterbennett: Regarding remmina. All I did was choose RDP from the protocol pull down and type my remote hostname in the entry box and press Enter. The window pops up but alternate between "Reconnection in progress. Ateempt 0 of 20..." and "... Attempt 1 of 20..."
[20:51:09] markk_: peterbennett: do you have something with multiple reference frames? something to get it thinking. and hevc? (can't test that here).
[20:52:30] peterbennett: gigem: Remmina – if i try that i get a weird error "you requested h264 gfx mode"
[20:53:25] peterbennett: gigem: but when I use the entry that I have created it works fine
[20:54:02] peterbennett: markk_: I don't know about reference frames. I can try hevc and 4K
[20:55:27] peterbennett: markk_: HEVC vaapi is fine (720p)
[20:55:53] peterbennett: CPUs 7% – 20% each
[20:56:44] peterbennett: markk_: H264 3840x2160 is fine
[20:57:10] markk_: peterbennett: ok – this is all promising:). last ask – can you check seeking? h264 should be fine. mpeg2 won't crash anymore – but you may find it drops back to ffmpeg and then deadlocks when trying to exit.
[20:57:45] stuarta: markk_: i'll fire up one of the other dev laptops with that has an i7 in it
[20:58:30] peterbennett: hevc 50fps 10bit caused a seg fault
[21:01:56] markk_: and it was going so well...
[21:02:53] markspieth: peterbennett: had a look at the latest patch. fix_amount is first signed then then unsigned. The rtcbase adjustment assumes unsigned. Is this intended
[21:02:55] markspieth: ?
[21:06:29] peterbennett: markspieth: fix_amount – it looks like an error
[21:07:00] peterbennett: You are right
[21:07:41] peterbennett: gigem: Better cancel that patch, markspieth found an error which could casue weird problems.
[21:08:00] stuarta: yay for code reviews
[21:08:20] markspieth: peterbennett: std::abs()
[21:08:44] gigem: peterbennett: K
[21:10:01] peterbennett: markspieth: "fix_amount = audio_adjustment * sign / 15" should not have "* sign" in it
[21:10:11] peterbennett: Is that what you refer to?
[21:10:27] gigem: Got remmina to connect using a profile. It was probably trying to connecting without a password. It's slower than rdesktop using default settings. :(
[21:10:42] markspieth: peterbennett: no. int64_t fix_amount = avsync2adjustms;
[21:11:09] markspieth: peterbennett: you already have sign in the line that mods rtcbase
[21:12:25] markspieth: peterbennett: should be int64_t fix_amount = std::abs(avsync2adjustms);
[21:12:51] markspieth: markspieth: or * sign :-)
[21:12:55] peterbennett: markspieth: Gotta go now – I will look at it
[21:13:03] stuarta: std::abs seems clearer
[21:24:51] markspieth2 (markspieth2!~yaaic@mythtv/developer/markspieth) has quit (Ping timeout: 244 seconds)
[21:33:00] markspieth2 (markspieth2!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[21:33:00] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth2
[21:37:22] markspieth3 (markspieth3!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[21:37:22] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth3
[21:39:35] markspieth2 (markspieth2!~yaaic@mythtv/developer/markspieth) has quit (Ping timeout: 240 seconds)
[21:39:58] MythBuild: Build 2019-render-freebsd12–64bit #32 is complete: Failure [failed test (failure)] – https://code.mythtv.org/buildbot/#builders/98/builds/32
[21:39:58] ** MythLogBot https://code.mythtv.org/trac/ticket/32 **
[21:40:32] MythBuild: Build 2019-render-freebsd11–64bit #32 is complete: Failure [failed test (failure)] – https://code.mythtv.org/buildbot/#builders/86/builds/32
[21:40:32] ** MythLogBot https://code.mythtv.org/trac/ticket/32 **
[21:40:55] gary_buhrmaster: probably not relevant here, but using qAbs was better then std::abs for some cases in the past in MythTV code (I don't recall the details, and I think it may have been both/either architecture and/or C++LEVEL dependent)
[21:41:27] peterbennett: std::abs looks like it may not apply to int64_t
[21:42:42] markspieth: https://en.cppreference.com/w/cpp/numeric/math/abs says otherwise
[21:43:22] markspieth: check with compilerexplorer
[21:43:55] markspieth: sign is fine too. both should optimize to the same number of instructions
[21:45:12] peterbennett: so fix_amount is first set to 10 or whatever is in the settings
[21:46:18] peterbennett: Then if the absolute value of audio adjust is over 200 it is set to (absolute value of adjustment) /15
[21:46:39] peterbennett: So now it has a positive value of, say 70
[21:47:55] stuarta: markk_: so your current vaapi fails under wayland, whilst vaapi2 uses (when setup) the /dev/dri device to access hwdecode
[21:48:31] MythBuild: Build master-freebsd12–64bit #78 is complete: Failure [failed test (failure)] – https://code.mythtv.org/buildbot/#builders/45/builds/78
[21:48:31] ** MythLogBot https://code.mythtv.org/trac/ticket/78 **
[21:49:46] peterbennett: markspieth: I am not sure where the signed / unsigned problem occurs.... Upon looking at it again it looks ok.
[21:49:50] MythBuild: Build master-freebsd11–64bit #106 is complete: Failure [failed test (failure)] – https://code.mythtv.org/buildbot/#builders/41/builds/106
[21:49:50] ** MythLogBot https://code.mythtv.org/trac/ticket/106 **
[21:50:53] markspieth: peterbennett: sorry you are correct. I mixed audio_adjustment and avsync2adjustms. Bugger.
[21:51:34] peterbennett: If it makes it clearer I can use std::abs(audio_adjustment) instead of audio_adjustment * sign where ever it is used
[21:52:06] stuarta: it certainly makes the intent clear
[21:52:06] markspieth: markspieth: it doesnt make it clearer as its obvious what it does. But whatever you like.
[21:54:02] peterbennett: According to that web page std::abs is for int, long, long long, intmax but I don't see int64_t – I am no expert on standard library ..
[21:54:45] peterbennett: markspieth: Talking to yourself again? :)
[21:55:08] stuarta: first sign of madness
[21:55:57] peterbennett: markspieth: So I will leave as is – I have not done anything specific for your 1.2x judder, I have not seen it, and maybe getting these calculations right will help with that.
[21:56:35] markspieth3 (markspieth3!~yaaic@mythtv/developer/markspieth) has quit (Ping timeout: 240 seconds)
[21:57:06] peterbennett: gigem: It looks like there is not actually the sign problem we had thought – so the patch should be OK.
[21:57:40] peterbennett: markspieth: Thanks for looking at it, even if it was not wrong it is good to look at some of this stuff over again.
[22:02:30] markspieth2 (markspieth2!~yaaic@mythtv/developer/markspieth) has joined #mythtv
[22:02:30] Mode for #mythtv by ChanServ!ChanServ@services. : +v markspieth2
[22:11:54] gigem: peterbennett: K. New build underway.
[22:12:19] Steve-Goodey (Steve-Goodey!~steve@2a00:23c5:7da3:4501:7a84:3cff:fedf:a99) has quit (Quit: Konversation terminated!)
[22:12:42] gigem: Now why does remmina (and rdesktop) insist on running fvwm instead of xfce? My x-session-manager alternative points to startxfce4.
[22:13:48] peterbennett: did you look at /etc/xrdp/startwm.sh
[22:14:45] gigem: Yes, AFAICT, it ultimately runs Xsession which has a run-parts that should run Xfce.
[22:15:21] peterbennett: Also when you logon there s a dropdown for session type, i usually use xorg, you can try others or customize the list
[22:15:28] markk_ (markk_!~mark@host86-166-192-129.range86-166.btcentralplus.com) has quit (Ping timeout: 250 seconds)
[22:16:01] peterbennett: Old versions used to use .xsession but I think it no longer does.
[22:21:02] gigem: peterbennett: You're the man. I had a 13-year old .xsession file!
[22:21:38] peterbennett: I think you need to remove that
[22:21:39] gigem: mark_: I confirmed your libass fix works for me on both Linux and Shield. Many, many, thanks.
[22:21:49] gigem: I already have! :)
[22:24:36] gigem: This also seems to be faster than before. It's still no x2go but it's serviceable and has opengl support.
[22:24:59] peterbennett: gigem: If it is slow there is a quality setting you may be able to adjust
[22:25:31] peterbennett: I don't know if that does anything I have not changed it.
[22:38:01] SteveGoodey (SteveGoodey!~steve@2a00:23c5:7da3:4501:7a24:afff:fe9d:c233) has quit (Quit: Konversation terminated!)
[22:42:36] gigem: peterbennett: The default quality is poor/fastest and I didn't change it. Don't get me wrong. It's doesn't perform badly. It's more that x2go is really, really fast and I'm spoiled because of it.
[23:33:36] Tobbe5178 (Tobbe5178!~asdf@2001:2002:51eb:d24e:41ff:3834:c5e2:c8f1) has quit (Read error: Connection reset by peer)
[23:48:09] gigem: peterbennett, tgm4883: Regarding that #mythtv-users discussion, perhaps we should include programid in the file name, as least for Schedules Direct users. That would allow accurate, after-the-fact lookups or program information.
[23:51:10] peterbennett: gigem: I am not crazy about that idea.
[23:53:37] peterbennett: You could give the recordings a full series name and episode name, also.
[23:54:43] peterbennett: But there may be repercussions
[23:55:13] tgm4883: You could do a database backup to the recordings drive instead, so if you lose the recordings drive you also lose your backup
[23:58:39] peterbennett: For those who never run the backup or never notice the backup is failing, etc. – we could just append a line to a text file on the recording drive with filename and some details.
[23:59:02] peterbennett: Each time a recording is created.

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