Either way tuner sharing or not the problem still exists where the buffer is at the Client and any keystroke like back, home you lose the buffer.... and the buffer is limited by space on the Client even though the server has plenty of space.
Maybe there could be a checkbox somewhere on the server or client that says it will treat all live TV watching as a recording (never buffered on the client).
Note: If you didn't like this option, you could leave it unchecked, so this added feature wouldn't affect you in any way.
That's exactly what Tuner Sharing does. I'm not sure if Tuner Sharing keeps a buffer on the server.
Tuner sharing uses a small buffer in memory, nothing on disk for an HDHR source.
For TVE (and I assume M3U) source, looks like it's buffered to disk.
1 Like
I think a quicker solution would be to let the user know how long the buffer would be when they hit pause based on the data rate of the channel being paused and the available client storage.
I have a related question.
As I understand it, with tuner-sharing off, the live-TV buffer is entirely on the DVR Client. The length of the playback buffer is dependent on the balance of available client memory and the bitrate of the live-TV source -- ultimately capped at 90 min.
So, for the nVidia Shield, if I add adopted storage to the Shield to 'expand' it's internal memory can/will the DVR Client make use of the extra adopted storage to enlarge the live-TV buffer and allow it to stretch out to 90 min for higher bitrate HD channels?
What I really miss is the ability to save the buffer ... Sometimes I am watching LiveTV for example the news and I see something I really would like to share with a family member not at home ... but there is no way to save it.
3 Likes
Yes. Add SD card to your shield pro. Shield tube has no SD slot. You would need USB.
This is the feature that I miss most from SageTv when I used it years ago.
1 Like
So I've been looking over the Channels API. Until I get around to it myself, it should be a very do-able project for an intermediate programmer to write a script (in a language of your choosing) that uses the Channels API to:
- Find all Channels clients on the LAN
- Foreach client:
2a) Poll its status
2b) If it's streaming something live (rather than a recording), and that stream is not already being recorded, start a recording of the stream
The trick is deciding when to stop the recording. For instance, an argument could be made that you should schedule the recording to keep going until the end of the current program. Problem with that is, say, you're channel surfing and you watch just a few minutes of each of a bunch of difference channels - you'd run out of available tuners real fast with that many concurrent recordings.
So you'd probably want to stop the recording when you observe that the client has stopped, or changed to a new channel.
I still use SageTV to watch a lot of LiveTV ... I do a lot of pausing so I am always a bit behind and if something comes up and I have to leave all I do is hit record in SageTV.... and I have everything from when I started watching until the end of the show. I use Channels DVR as a backend to SageTV.
1 Like
Could add a minimum time of a recording as well. Not sure if the API exposes recordings times but if it does then you could tweak it so that any recording less than N minutes is trashed. Keeps you from having a ton of 30 second or less recordings cluttering the admin pages.
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