The thing I'm looking for is further down for the actual Encode Config.
What about further down the page for the Encoding Config?
Thanks. The second screenshot had what I was looking for.
I was able to reproduce something that sounded like what has been described on this thread when I had my video size set to Auto and then changed the resolution of the streaming device that was being captured. Once I changed the video size to 1080p it stopped exhibiting the issue.
The issue seems to be that when the capture device resets the encoder, it behaves poorly and causes all sorts of problems. I experimented with rewriting the timestamps as it goes and that did not improve the situation for me.
It seems that your TBS system doesn't handle the video resolution change on the streaming device as well as my LinkPi. Is there a firmware update available for the TBS encoder that you haven't applied? Is there a way that you can turn off any sort of content/resolution changing on your streaming device?
Thanks for looking into this eric, no I'm on the latest firmware and I've looked and there's nothing that I've seen to change it's just a defect with the encoder.
Are you saying that even if I switch to HLS (if possible) that it's not going to fix it? I suspected it was a video res change, which is stupid because you tell it to always output 1080p but it doesn't. The provider's Technicolor Android TV STB drops the HDMI output to the encoder when it sees an IPTV drop upstream from the provider, and the encoder then reverts to a static 480p (?) NO SIGNAL screen until HDMI comes back. It's a very solid and reliable encoder otherwise, but tech-wise at least five to six years old.
You could replicate this on your end by pulling the HDMI cable out of your LinkPi while you're recording the stream, wait a sec then plug it back in. This is broken STB behavior to me but it is what it is.
Yeah, in my testing HLS did not solve this. Neither did putting the timestamp rewriter inline with the recording.
I'll try that, but I think that it replicated it by changing the resolution/frame rate on my Apple TV.
1 Like
You might find that the LInkPi responds differently when HDMI is lost vs. an upstream res change, or does a res change also drop HDMI? From what I've seen these encoders all have a static no signal screen, the only question is whether they change the output stream res or not even if you have it configured for a specific res (i.e. not auto).
I have a TBS, UrayCoder and an iSeevy btw, but I've only seen this issue on the TBS so far. But if they all output their no signal screen at whatever default res they have, anytime you lose HDMI you'll see this. It kind of makes sense because they're not encoding from a source at that point.
It's an edge case depending on the device you have connected to the encoder for sure. For me the bug is on my provider's STB, it's really stupid that their video player drops HDMI for transient IPTV issues. They should have their own no signal screen instead of just going to black.
FWIW I only see this issue on CBS and for that it's mostly golf and football, so it's not like an issue across all of my provider's channels. We've bugged them about getting this fixed and it's gotten better but I'll see a CBS signal drop every couple of hours, which means all of my sports recordings on Channels for CBS have this issue.
Is there any update for this?
What specific encoder do you have? What is the resolution settings you’ve specified?
There is nothing I’ve found that we can do while the recording is running to handle the encoder restarting like this.
I was just hoping for a way to run the Fix Video Timestamps right after the recording was finished or editing the comskip to run this command beforehand to fix the recording duration. If this is not possible, then I can keep going in an doing it manually like I am doing now.
No, if it's not already running it on these videos (which it will when there are the sorts of failures that happen on OTA or Cable TV) there isn't a way to make it run when it completes.
I had previously asked for more clarification as to the details of what your source is:
I see now that you've recently submitted diagnostics, and based on what I see there, if you update to the latest pre-release and put this tag in your m3u source for each of the channels:
tvc-stream-timestamps="rewrite"
It will add the rewriter on at the time of streaming and it may repair what's going on.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.