I have one of each of the 2019 versions, the Tube has an SD card slot and the Pro has 2 regular USB connectors
This post has begun to tire me so. The buffer has been discussed exhaustively in numerous other threads. I must be late for my afternoon coffee. Might as well go straight on to evening cocktail and call it good.
Then don't read it .... why can we throw around ideas nothing wrong with that ... if you have a problem do not read it no one is forcing you geez.
Just bouncing ideas of each other, keep it civil so the developers do not have a reason to lock threads.
Dont mind PsPerry. Hes just grumpy. Its past his bedtime.
@VTTom
If you where creating rules for when to record live recording. I would maybe add a rule.
3) Dont begin recording unless channel has been tunes for 60+ sec.
4) Delete recordings if 48hrs after creation
4a) Save recording if user manualy says "save recording"
That would stop it from recording a bunch of 3 second recordings as you flip through channel
1 Like
I was wondering why he was grumpy ... he is a real nice guy on here and helpful.
1 Like
Why is my Live TV buffer so small?
The Live TV buffer is on the client device and is constrained by the amount of free disk space available. We reserve 500-700MB of free disk space for the OS to ensure that normal operations continue (and to prevent Android Low Disk Space pop-ups from happening).
Confusingly, many times the free disk space reported by Android and iOS/tvOS is not accurate and will say more disk space is free than really is. We have to operate in the world of what is really available as reported by the system and not what is displayed, because otherwise it will actually run out of disk space and cause problems.
What is the Tuner Sharing Buffer?
It's a small in-memory buffer with a maximum size of 16MB that only contains data that has not yet been read by any consumers. This means that regularly the amount of data in the buffer is a couple hundred milliseconds worth of data. Not anything that would be worth saving.
What are other kinds of buffers you have?
When streaming remotely or with transcoding, there is a 2 hour on-disk buffer of what is being watched while it is being watched. This buffer is per-client and is different than the format that is used when recording. Unfortunately, the format and configuration of this on-disk buffer does not lend itself to being used by our recording subsystem.
Why can't you just...
We can! There are lots of things that we could do to handle cases like the "I want to retroactively record the thing I've been watching". The reality is, all of those things that we could do are complicated and have the opportunity to introduce new bugs and those bugs could potentially cause recording failures even for people who never wanted to use these new features.
We all know the feeling of losing a recording you really wanted to have and so we work really hard to prevent those things from happening. This means we move slowly and deliberately when introducing new large changes to the recording pipeline.
But the solution I have in mind is easy!
A lot of solutions that sound easy end up having a lot of surprising issues and edge cases that would be hard for anyone who hasn't been seeing years of support requests to anticipate.
We've been able to strike a delicate balance in many places to be able to support situations where people have just enough computer resources to be able to very happily use Channels in their environment, but if we increased the CPU, disk or network utilization by a relatively small amount, it would start to have problems.
We'll do what we can when we have time to explain some of these pitfalls and surprising issues.
Does this mean retroactive recording will never happen?
Nope. It just means that we don't know if or when it will. We are always considering the requests of users when we develop new features and fix issues, and are on the lookout for improvements we make that could make features that were previously hard a lot easier now.
8 Likes
Calm down cowboy. It was a mostly tongue in cheek comment. Mostly.
OK going to ride my horse to the old town road and calm down.
1 Like
Sounds like a nice vacation.
I have seen on occasion when using multiple clients with tuner sharing ... the buffer sometimes fills up and abruptly ends the stream.
Can you give me an approximate time of when you submitted diagnostics from the client right after this happened?
I have 4 clients running the same show at the moment to see if I can recreate it... I will look at some of the old logs.
2022/01/23 15:11:11.569837 [TNR] Sharing existing connection to 107829D3/0 for ch8.1 KGW (clients=3, len=0)
2022/01/23 15:15:28.413332 [WRN] Buffer for 107829D3 ch8.1 is more than 50% full (clients=3, len=33554888)
2022/01/23 15:15:45.071186 [WRN] Buffer for 107829D3 ch8.1 is more than 75% full (clients=3, len=50331760)
2022/01/23 15:15:46.554404 [SNR] Statistics for ch8.1 KGW: ss=100% snq=100% seq=100% bps=9127609,1598752-14803872 pps=781,150-1268
This is when it picked it up again ....
2022/01/23 15:17:18.768221 [TNR] Sharing existing connection to 107829D3/0 for ch8.1 KGW (clients=3, len=0)
more recent ....
2022/05/23 05:04:31.891905 [WRN] Buffer for 13147C7B ch723 is more than 50% full (clients=3, len=33555064)
2022/05/23 05:05:03.822916 [WRN] Buffer for 13147C7B ch723 is more than 75% full (clients=3, len=50332596)
2022/05/23 05:05:29.395063 [WRN] Buffer for 13147C7B ch723 is more than 95% full (clients=3, len=63754672)
2022/05/23 05:05:34.763524 [WRN] Buffer for 13147C7B ch723 is more than 99% full (clients=3, len=66437964)
2022/05/23 05:07:07.961826 [SNR] Statistics for ch723 FS1HD: ss=86%,0%-88% snq=98%,0%-100% seq=98%,0%-100% bps=4072420,0-7318464 pps=350,0-633 err=3% sigerr=1% neterr=2%
2022/05/23 05:07:07.962473 [SNR] Statistics for ch723 FS1HD: ss=86%,0%-88% snq=98%,0%-100% seq=98%,0%-100% bps=4072420,0-7318464 pps=350,0-633 err=3% sigerr=1% neterr=2%
2022/05/23 05:07:07.974293 [SNR] Statistics for "TV/First Things First/First Things First 2022-05-23-0429.mpg": ss=86%,0%-88% snq=98%,0%-100% seq=98%,0%-100% bps=4072420,0-7318464 pps=350,0-633 err=3% sigerr=1% neterr=2%
2022/05/23 05:07:07.982836 [TNR] Closed connection to 13147C7B/0 for ch723 FS1HD
@Edwin_Perez I've checked and I don't see any diagnostics submissions from your client devices. There's nothing we can do without seeing those.
1 Like
IIRC, buffer warning errors ([WRN]) are caused by two situations:
- either your server's disk cannot keep up with the incoming data, or
- your network cannot consistently deliver the data to your clients within an acceptable timeframe.
1 Like
Next time if it happens again, I will submit ... I usually watch my morning sports shows in 3 locations... all live.
I thought the tuner sharing buffer is in memory? so why would it be disk... so lets eliminate that.
Because for recording or transcoding the buffer is written to disk; if the disk cannot keep up with data filling the buffer, the buffer gets full. The buffer is in memory, recordings and the streaming cache are not.
That is not my problem as it is livetv ... but thanks for the input.
Eric thank you for taking time to respond to our desires and explain (VIOLENTLY MURDER) why my dreams are unlikely to happen. Lol.
I also really like the two topic titles i quoted. But i assure you my solution is easy . . . For me.
So @eric here is my plan. I tell you I want the worlds most bad ass DVR. Thats my whole plan. Its easy for me. I don't have to do any of the work. Ummm. . . Eric shouldn't you be working right now?