After applying the 2022.10.18.0345 update, I scheduled 5 recordings for HGTV and 5 for the Food channel. I didn’t see any errors in the logs, however I did notice that commercial detection doesn’t seem to be working for the Food channel and when I try to seek forward in the timeline it freezes. I didn’t notice any of these issues with HGTV recordings…
1 Like
I've noticed this problem mostly on the prime time 8p-10p recordings. If I notice the errors and schedule to rerecord the second showing later that night or next morning, they record just fine. Seems to be something with the way they are streaming the prime time shows.
2 Likes
I had the prime time theory as well but havet proven it yet…
Ive had a couple of recordings complete this morning with no errors, and i think that commercial detection is non optimized in this version of the pre-release. i.e. comskip is being used.
Those two recordings looked great, and comskip worked as expected.
Another just completed with an error, but not the audio segment error?
However, the time duration was only 5 minutes. This is similar to a couple of recordings from earlier in the week. No error on the client, just a recording with wrong duration.
I did notice that a breakpoint was triggered in the logs @eric , but the recording didnt have the same audio segment error text . Seemed to be a different error.?
2022/10/18 07:01:10.122996 [DVR] Running commercial detection on file 3283 (TV/Alaska The Last Frontier/Alaska The Last Frontier S05E03 2015-10-18 Fear and Floating 2022-10-18-0559.mpg)
2022/10/18 07:29:41.796855 [DVR] Commercial detection for Alaska The Last Frontier S05E03 2015-10-18 Fear and Floating 2022-10-18-0559.mpg finished with 12 markers in 28m31.750759174s.
2022/10/18 07:48:00.635454 [NAT] Successfully mapped port 8089 using upnp
2022/10/18 07:58:59.960726 [DVR] Waiting 39.284ms until next job 1666097940-ch6101 Alaska: The Last Frontier
channels-dvr(12072,0x70000c4c7000) malloc: *** error for object 0x103045600: incorrect checksum for freed object - object was probably modified after being freed.
*** set a breakpoint in malloc_error_break to debug
SIGABRT: abort
PC=0x7fff50d9fb66 m=3 sigcode=0
Ive just submitted diagnostics from the DVR web interface:
fcdc42f3-2139-4cb4-aa24-09555ac65436
In the meantime ive got deadliest catch scheduled for primetime this evening, and several others scheduled during the day. Ill scheduke a couple more on food channel and hgtv for primetime as well @scottuf
I have another couple of trashed recordings. One is on food network, “food paradise”, another 2 on discovery “airplane repo”
Food paradise has length of 425 minutes and doesnt play.
One of the Airplane repos plays a bit - appears to have correct length, but if i skip into the file the playback pauses for quite some time but eventually starts playing but with NO AUDIO.
The other has “recording interrupted” warning in the client, correct length but plays after long delay with NO AUDIO
Ive saved the files for these in case that helps.
There were errors on both shows in the log, but one gave a debug dump and the other error for Airplane repo didnt have extra debug info. So much for my “prime time only” theory @scottuf
Submitted diagnostics:
80d784ed-c26a-47a1-af91-582663782789
1 Like
On the plus side, maybe a fix can be deployed before prime time tonight!
1 Like
Please try out this latest build. It should fix the issues folks have been seeing.
2 Likes
If audio feeds are separate, is it possible we could see 5.1 pop up in the future?
5.1 seems doubtful. These feeds are generally targeting people watching from a computer, which tend to not have surround sound setups.
Thats what I figured. What is interesting is Apple having a lot of Atmos and 5.1 content. Also headphones and iPads etc are supporting these so I was hoping TVE would have a reason to offer in their apps and didnt know if that was reason for the change. 2 channel audio is the bummer in my setup with a 7.1.4 Atmos soundbar.
TVE streams come from the networks' websites. Usually those are separate/different than the streams in their apps.
@eric not sure if this needs to be a new thread but Deadliest Catch on Discovery recorded tonight and everything looks like it should be an hour recording. It shows on the client as 6 minutes.
I submitted diagnostics just now...
2022/10/18 19:59:50.001578 [DVR] Starting job 1666137590-87 Deadliest Catch on ch=[6101]
2022/10/18 19:59:50.626798 [TVE] stream timestamps: discovery: start_at=2022-10-18T19:58:46-04:00 end_at=2022-10-18T19:59:42-04:00 live_delay=3.906783813s
2022/10/18 19:59:50.628950 [TNR] Opened connection to TVE-Cox for ch6101 DISCOVERY
2022/10/18 19:59:50.629581 [DVR] Recording for job 1666137590-87 from TVE-Cox ch6101 into "TV/Deadliest Catch/Deadliest Catch S18E26 Norse Inheritance 2022-10-18-1959.mpg" for 1h1m39.998148387s
2022/10/18 19:59:50.684905 [IDX] Generating video index for job 1666137590-87
2022/10/18 21:01:33.909634 [SNR] Buffer statistics for "TV/Deadliest Catch/Deadliest Catch S18E26 Norse Inheritance 2022-10-18-1959.mpg": buf=0% drop=0%
2022/10/18 21:01:33.920019 [TNR] Closed connection to TVE-Cox for ch6101 DISCOVERY
2022/10/18 21:01:33.927488 [MTS] Statistics for "TV/Deadliest Catch/Deadliest Catch S18E26 Norse Inheritance 2022-10-18-1959.mpg": skipped=0 unhandled_packets=1 discontinuity_detected=92 transport_errors=0 invalid_pts=0 invalid_dts=0 saw_pcr=true saw_pmt=true highest_pts=3286.297344
2022/10/18 21:01:33.930950 [DVR] Finished job 1666137590-87 Deadliest Catch
2022/10/18 21:01:34.075025 [DVR] Processing file-11745: TV/Deadliest Catch/Deadliest Catch S18E26 Norse Inheritance 2022-10-18-1959.mpg
2022/10/18 21:01:34.429092 [DVR] Running commercial detection on file 11745 (TV/Deadliest Catch/Deadliest Catch S18E26 Norse Inheritance 2022-10-18-1959.mpg)
2022/10/18 21:04:46.716458 [DVR] Commercial detection for Deadliest Catch S18E26 Norse Inheritance 2022-10-18-1959.mpg finished with 10 markers in 3m12.2874864s (7 threads).
My deadliest catch was ok
But a recording on investigation discovery did something similar it shows 14min but is longer and plays past the timeline and then after awhile starts back at 1 minute continuing to play. Pressing a skip completely confuses playback and starts back somewhere in the first 13 min. I haven’t ran regenerate or fix time stamps in case you want the file.
Logs submitted
2392e38e-c85b-4b00-b5f2-748ba284f856
Logs are very very busy during this time good luck!! I do know slapman and I are running Ubuntu
@ 2022/10/18 18:02:19.149801 is the start of the recording
On a side note there are tons of these errors but not necessarily on that recording
Non-monotonous DTS in output stream 0:1; previous: 75047575, current: 74797965; changing to 75047576. This may result in incorrect timestamps in the output file.
Version 2022.10.18.2139
I updated to prerelease on mac mini server
#### v2022.10.18.2139
and worked great, (deadliest catch) - although commercial detection was via comskip, so lots of “commercial in progress” banners just like the good old days before alternate optimized commercial detection.
However, more importantly there were no errors in the log, the playback was flawless with no transport control hicckups or weird indexing confusion with the file.
Ill schedule some more test recordings during the day today on food network, hgtv, and discovery.
edit:
I had another anomaly show up on one of the test recordings mentioned above this morning.
This was a discovery show “unearthed” season 2 episode 1
The length is only 6 minutes. Bummer.
There was no breakpoint or error in the log file from today.
Made a bunch more manual recordings this morning. some worked, but im still seeing several with zero minute times, some with 6 minutes as @slampman reported.
I've setup some test recordings on my development system as well to try to see if I can capture these issues and see what's happening. Thanks for the reports, everyone.
2 Likes
@eric I remembered we had this same issue last year (recordings showing 6 min) not sure what @tmm1 did to fix as it wasn't obvious in the thread but maybe this helps
I've been able to identify the issue here and this new encoder platform/ad insertion platform that is being used for some of these Discovery channels is creating some nonsensical feeds where the audio and video timestamps don't match up and aren't synchronized in how the HLS spec specifies them to be.
It's going to require a lot more work and engineering to fix these situations and I'm not sure how quickly that will be done. We'll keep you updated as we progress.
4 Likes
I've been having problems with Discovery+ for several weeks - all the channels on Plus have been acting up - freezing, stopping, unavailable - while all my other streaming services are fine.
I suspect it must be them preparing for the merger. A few days ago all of Discovery+ was out completely for two hours - during prime time no less.
I hope it get fixed.
Im curious about discovery +. Are these dropouts when you watch through the discovery + app, or via channels?
The reason i ask is that the past couple of weeks ive been using playon cloud with paramount +. Channels has a fantastic integration with playon cloud. Its works very very nicely and recordings end up in the channels dvr.
I have been considering a discovery + subscription, and using playon anytime credits to record some of the discovery shows
(((. Edit:
ON DEMAND NOT REALTIME.
i.e. i dont care of i watch gold rush or deadliest catch a day or two later that live channel.
for me, and then have channels pull them from playon. ))))
It works really well with paramount plus. My subscription is running out in a week or so, so ive been recording some shows that i just wont have time to binge watch.
It might be a workaround for some with discovery + accounts.
I dont have one so im curious..if anyone can confirm losing if playback of non linear (on demand content) has the same problem with the streams.
1 Like
Last night I recorded Gold Rush. Looking at the logs it recorded just fine, but when I go to play it the file is only 11 mins long. The file size is 6.7GB. If I play in VLC it stops at 11 mins as well. I opened it in Handbrake and that says its 2hr 18min long. Not sure if its the same issue.
Logs: a628eecf-9e13-4ea7-9be8-a550b1d54e75
Playing it in the web player is says 2 he 13 mins at the top, but the player is only showing 10:34
