BETA: New in-memory Tuner Sharing Buffer

Hi folks. Could you try out the latest beta when you get a chance and let me know if everything is continuing to behave as normal? We've made some improvements to our logging infrastructure in the latest build around TVE that should have no user-facing changes (but potentially fix some strange issues where logs ended up in the wrong file from time to time). We just want to make sure there aren't any regressions. There isn't anything specific that is needed to test, just wanting to make sure there aren't any panics/crashes or other strange things that crop up during normal usage.

We've been running the new logging infrastructure in our beta apps for a couple weeks without incident, so we aren't expecting any issues.

1 Like

Sure, does this only affect those using the Experimental New Streaming Buffer (Topic Title)?

Like debug recording logs for back-back recording with overlap on the same TVE/M3U Channel?
I've noticed that, but hardly ever look at them and figured you guys knew about it,

It impacts both — we just had such a nice group of testers here I threw it in here for feedback.

That’s exactly the sort of bugs we’ve tried to tackle with these changes.

1 Like

Scheduled TVE channel 10 minute recording is done, but it still shows as recording in
schedule

manage shows
Screenshot 2022-08-19 at 16-49-55 Channels Manage Recordings

calendar.
Screenshot 2022-08-19 at 16-50-32 Channels Calendar

Last log entries are

2022/08/19 16:10:02.000298 [SNR] Buffer statistics for "TV/Canary REELZ Recording/Canary REELZ Recording 2022-08-19-1600.mpg": buf=0% drop=0%
2022/08/19 16:10:02.093758 [MTS] Statistics for "TV/Canary REELZ Recording/Canary REELZ Recording 2022-08-19-1600.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=0 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=617.659233

Normally after it's done recording I would see this (below from last recording)

[SNR] Buffer statistics for "TV/Canary REELZ Recording/Canary REELZ Recording 2022-08-18-1600.mpg": buf=0% drop=0%
[TNR] Closed connection to TVE-Comcast_SSO for ch6095 REELZ
[MTS] Statistics for "TV/Canary REELZ Recording/Canary REELZ Recording 2022-08-18-1600.mpg": skipped=0 unhandled_packets=0 discontinuity_detected=0 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=611.692378
[DVR] Finished job 1660863602-ch6095 Canary REELZ Recording
[DVR] Processing file-970: TV/Canary REELZ Recording/Canary REELZ Recording 2022-08-18-1600.mpg
[DVR] Running commercial detection on file 970 (TV/Canary REELZ Recording/Canary REELZ Recording 2022-08-18-1600.mpg)
[DVR] Commercial detection for Canary REELZ Recording 2022-08-18-1600.mpg finished with 4 markers in 2m5.408329917s (2 threads).
1 Like

Can you submit diagnostics when it’s still in this state?

Logs have been submitted as 5b7c9d9e-b30f-4b25-b9e9-3e5eaaebbcdb

1 Like

Thanks for the info. I’m digging into the diagnostics now.

I’m rolling back the change until I can come up with a fix for this issue.

2 Likes

Didn't see this in the log, is the stream still open?

Doesn't appear to be any network activity on my NAS.

No, the stream isn’t open, but it’s stuck in the close process. It looks like there’s a race condition that can cause a deadlock on shutdown of a connection that I am trying to reason out. You should be able to update to the new release that just went out without any corruption.

1 Like

Thanks, that should help my 4 Channels DVR servers that I updated!

But... the one that was stuck and I submitted diags on thinks it's busy.
Trying to update results in this message

Version 2022.08.19.2146
Waiting to upgrade to 2022.08.19.2329...
! Upgrade now

So for anyone else stuck here, I'm going to click Upgrade now.
And after the updating it resumed normal operation.

[DVR] Processing partially recorded expired job 1660950002-ch6095 Canary REELZ Recording
[DVR] Processing file-973: TV/Canary REELZ Recording/Canary REELZ Recording 2022-08-19-1600.mpg
[DVR] Running commercial detection on file 973 (TV/Canary REELZ Recording/Canary REELZ Recording 2022-08-19-1600.mpg)
[DVR] Commercial detection for Canary REELZ Recording 2022-08-19-1600.mpg finished with 2 markers in 3m23.177776698s (2 threads).

The only issue is the recording shows as interrupted, although it wasn't.
Screenshot 2022-08-19 at 17-13-43 Channels Manage Recordings

Glad we caught it early and it was only a Canary recording, not something I wanted to archive.
That's why I don't use a task to auto-update to the latest pre-releases.
Prefer to be there to make sure it works.

1 Like

You sure? or just testing?

I think i'll safely update only one of my servers this time!
Does an hsltube M3U HLS channel count for testing this?

I’ve done some preliminary tests that didn’t replicate the issue, but I also did those tests on the previous build and they passed, so some of these things will only surface once in a while and you just got unlucky (but lucky for my debugging).

Definitely.

This is one of the reasons we’ve don’t have the betas auto-update. It’s better to have less people updating immediately in case there are issues with the build.

1 Like

OK, have an upcoming curl manual scheduled by task recording of one in an hour on one of my DVR's and will update that server and let you know how it goes.
Scheduled to finish recording at 3AM UTC Tomorrow

As I'm sure you know, I do manual recordings using the curl method (last diags was one) so there may be something different with those. I'm also using that method for the one I'm about to test with the hlstube M3U source.

I’ve found another issue with the logging regarding recording ending and have started another build. Thanks for your patience and testing.

1 Like

OK, just updated to

before my recording kicks off in 8 minutes. Cutting it close!

Looking good Eric! Recording finished without any issues.

2 Likes

Thanks everyone for your help on this! The new Tuner Sharing Buffer has been enabled for everyone in the latest pre-release build.

1 Like