Pause LiveTV for 90 minutes?

[Edwin_Perez]

Then You have to manually delete all the recordings that you record from the start instead of pausing. Also If I am watching livetv and I hit record and start watching the recording it will not continue to the next airing show. The way the buffer currently works is just a pain in da butt.... but I like ChannelsDVr so will live with it.... but don't care for the buffer implementation.

[Michael_Birk]

Personally, I only do long pauses occasionally, so deleting a partial recording is not much of burden for me. You can setup to record an extra 120 minutes after the program ends, that should be enough for almost anybody. Of course for short pauses or shows that are not that important to me, I don't record.

[2lamas]

@dschaper

LiveTV is purely a connection between the HDHR and the client. No server involved unless you turn on Tuner Sharing.

I have tried this with tuner sharing enabled. LiveTV was still limited to the point I connected to the stream, even if I have a second unit tuned to the same channel. I might need to try this again with the latest version, but I hadn't seen anything addressing this.

@Kryptonyte

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.

I would love for everything to go through the server. I'm on a wired Gb throughout, so there's no issues with the server being the only connection for the HDHR, and everything else being served via the server. The gains in reliability for me would appear to be pretty big, and the server by far has a larger RAM buffer available than any of the clients, not to mention that "disk buffer"

[2lamas]

@Edwin_Perez

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.

This would be an automatic feature of the server buffering the video stream and proxying it to the clients. The server could simply flag it as a "recording" instead of "LiveTV" and it's done. Treating everything as a recording should make the clients simpler, you would think. They would only run in 1 configuration (either with server or without)

[2lamas]

@Jay1987

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

My take would be:

1. Channel is tuned - if no existing recording is happening, start recording. If an existing recording is happening, start playback at the current position.
2. Channel is changed or client disconnects and channel has more than 60s recording time: continue recording for 60s and then stop/delete
3. User presses Record - mark this as a recording and do no further operations.

You would also have to address what happens when LiveTV is going ontop of a recording - when the recording ends, you would start a new recording. I would argue that this happens the same as the guide recordings - so at the end of a show the next show's recording would start, there might be a 0-5 min overlap - depending on settings. You might also want to have a configurable time to automatically drop the last show - maybe 30 min into the new show?

I'm sure I've missed an edge case or two, but that would seem to cover the common ones I can think of.

[racameron]

@2lamas

Treating everything as a recording should make the clients simpler, you would think.

Channels originally had no DVR capabilities. It was originally developed solely as a live client for HDHomeRun tuners. This legacy persists, and the live viewing aspect is still very important. The client-focused approach is paramount to ensuring a super low-latency experience compared to SiliconDust's poor excuse for software.

This thread has brought to the surface a few issues:

• Some users want a server-first approach (which is not how Channels was developed) because they have become accustomed to cloud-type services, and want everything to work that way
• While such a feature (server-based buffers) is entirely possible, it is extremely non-trivial, and requires reworking how the server and clients work. (This is not version 1.0 2.0, this is 1.0 4.0.)
• If this is a must-have feature, Channels is not the software for you. (MythTV, SageTV, Tvheadend, etc., all use a server-based buffer for clients; feel free to explore those avenues.)

Seriously, this thread—and the many before it on the same topic—have beaten this particular horse to death ten times over ...

[2lamas]

@racameron

Seriously, this thread—and the many before it on the same topic—have beaten this particular horse to death ten times over ...

I know about the origin of Channels, and I have looked at MythTV and Plex and Emby as well. Obviously I chose Channels over the other solutions.

I still would say that my above additions would easily handle >95% of the use cases and only require a minimum of modifications on the client, since the LiveTV would now be a recording in progress. The rest is all server based, and that is admittedly more involved especially when considering a viewer that's watching several shows in a row on one channel, or channel flipping. I believe we have those covered - although I only implied that a less than 60s run of a channel would be stopped and deleted immediately since there is no meaningful content there. That way channel flipping wouldn't result in tuner unavailability. Also, given the speed of all server side processing, the latency for this process over just tuning into a channel as we do today should be very minimal. In fact, since there would always be "shared" tuning with this model, it might even be less latency, since there's only 1 tuner client and active management of tuners.

[Edwin_Perez]

I am getting closer and closer to using other products and you keep pushing me and others in that direction.

Just Kidding lol I love channels and always recommend it.

[2lamas]

I like the Channels UX, it is slick and works well. The others I've tried have not been as friendly or acceptable to less technically adept folks in the household. Channels DVR works well. As of 8 months ago, it works better and more reliably than Plex or Emby, and MythTV just didn't have what I needed at all - namely an ATV client. There is one - but it does not look well supported.

[racameron]

@2lamas

I still would say that my above additions would easily handle >95% of the use cases and only require a minimum of modifications on the client, since the LiveTV would now be a recording in progress.

Do you have evidence of this? Your statements without concrete examples reek of a PHB hand-wavy "get it done".

@2lamas

Also, given the speed of all server side processing, the latency for this process over just tuning into a channel as we do today should be very minimal.

Can you account for the resources of everyone's servers? This statement is naive at best, and corporate suicide at worst; judging from the numerous posts complaining about the quality of twice-removed last-gen Fire TV devices and the desire for Roku clients makes the willingness of users to invest in high-end devices suspect.

@2lamas

In fact, since there would always be "shared" tuning with this model, it might even be less latency

When used with a physical HDHomeRun tuner, live viewing always introduces extra network traversal, and therefore extra network latency. This is an unavoidable fact: going from A B C will always be slower and higher latency than going directly A C.

• A – HDHR tuner
• B – Channels DVR
• C – Channels client

[Edwin_Perez]

@racameron

When used with a physical HDHomeRun tuner, live viewing always introduces extra network traversal, and therefore extra network latency. This is an unavoidable fact: going from A B C will always be slower and higher latency than going directly A C.

Now that analogy I like. except when using tuner sharing it goes ABC. Which is the preferred way if you have limited tuners.

[TexasYeti]

Just in case the developer is gauging the development wishes of the users, I thought I would jump in here and say I agree.

Seems like you could just have every tuner "record" automatically (just not show up in the recordings listings) using the server. Then auto delete when needed.

This also serves the purpose of already having the buffer there if you decide you want to record the program, mid-program. Example, you are watching a movie and need to leave. Hitting record will save the beginning portion that you already watched so that the whole movie is recorded.

Functionally this is what TiVo does. Each tuner is just recording constantly in the background and allows you to jump between channels with the buffer intact - without hitting record.

Since the DVR can already record multiple channels at once, I dont see why it couldn't record by default and use that as a buffer instead of a client side buffer.

maybe an option to toggle: clientside or serverside buffer.

[2lamas]

@racameron

@2lamas

I still would say that my above additions would easily handle >95% of the use cases and only require a minimum of modifications on the client, since the LiveTV would now be a recording in progress.

Do you have evidence of this? Your statements without concrete examples reek of a PHB hand-wavy "get it done".

In short, yes. We already have recording playback - the only difference is how to manage initiating the recording and whether that could be done solely at the server or if the client "knows" more than it should, and requires a minor change.

@racameron

@2lamas

Also, given the speed of all server side processing, the latency for this process over just tuning into a channel as we do today should be very minimal.

Can you account for the resources of everyone's servers? This statement is naive at best, and corporate suicide at worst; judging from the numerous posts complaining about the quality of twice-removed last-gen Fire TV devices and the desire for Roku clients makes the willingness of users to invest in high-end devices suspect.

Short answer here - minimum requirements would need to be met. This won't work on a wifi connected NAS running on an original RPi. Not everyone is trying to run a DVR on a shoestring. I'm not advocating for a LCD on the approach, just an option for those with the appropriate hardware to utilize that hardware for a much better UX experience.

@racameron

@2lamas

In fact, since there would always be "shared" tuning with this model, it might even be less latency

When used with a physical HDHomeRun tuner, live viewing always introduces extra network traversal, and therefore extra network latency. This is an unavoidable fact: going from A B C will always be slower and higher latency than going directly A C.

• A – HDHR tuner
• B – Channels DVR
• C – Channels client

How long is your cable run? How fast is the speed of light? It's a simple physics problem. The code in the DVR server will be the slowest part of that calculation, and it's going to be fast enough that you won't be able to tell (with the aforementioned base hardware requirements.

[maddox]

Thanks for the feedback everyone.