Gold Rush failed on Friday. It said it was interrupted but recording didn't work and wasn't playable.
Interesting. This is helpful to know it isnt something on my end. So thanks. @koltasi
Seems there are a variety of “failure modes” , some more severe than others. I recorded Gold Rush Friday night as well, and it completed without error with no interruption warning marker, and the length seemed correct. However it was unplayable in channels or VLC. Size was over 6GB.
Sunday morning I manually recorded the rebroadcast, and it completed again without the interrupted red flag, but the commercial detection was currupted, and the feed must have dropped about 5 minutes of program material and inserted the blue commercial in progress banner.
I did try rescanning the discovery channel this morning, and it did complete a manual test recording of a different program without any issue. Im making another test this evening during primetime to see if there is any rhyme or reason to the intermittent streams. Hoping the rescan fixed something..
edit: still experiencing recording issues.
Anyone see this?
2022/10/17 19:00:47.021191 [DVR] Error running job 1666051140-ch6101 Street Outlaws: No Prep Kings: audio segment out of range
2022/10/17 19:01:04.980851 [TNR] Closed connection to TVE-Cox for ch6101 DISCOVERY
Same exact issue on my end especially with Food and HGTV. Seeing “audio segment out of range” errors in the log files.
1 Like
Can someone submit diagnostics after seeing that out of range issue with this pre-release or newer?
2 Likes
Ive updated the dvr beta and set up a bunch of recordings. Ill send diags as soon as i capture the error. Thanks Eric for all you folks do…
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.