Feature Request: Allow multiple buffers to remain in the background

Channels DVR Server Feature Requests
#1

Last night, I had a live show paused on my Apple TV for about 15 minutes. When I went to resume the show, I accidentally hit the Home button. When I re-opened the app, it resumed playing the same channel, but it was playing live and there was no longer any buffer saved that I could use to rewind. It would be nice if the Channels DVR server could maintain buffers in the background.

Expanding on this, it would be nice if Channels could behave live a traditional set top box where you can have multiple live buffers that you swap between. For example, it would be nice if I could swap to a different channel during a commercial break, swap back to the original buffer after a few minutes, and rewind to the end of the commercial break if I switched back too late.

I would implement this feature as three different settings:

  • The number of buffers available
  • The maximum length of each buffer behind the current seek point
  • The amount of time a buffer can be totally inactive before it is closed

To illustrate, imagine that I have my settings as follows:

  • Buffers: 2
  • Buffer Seek-Back Length: 1 hour
  • Buffer Timeout: 2 hours

Scenario 1

1:00pm

  • Begin watching Channel A

3:00pm

  • It is possible to rewind to 2:00pm (1 hour seek-back buffer)
  • Pause Channel A, leave app open

7:00pm

  • It is still possible to rewind to 2:00pm (seek-back buffer calculated from current seek point)
  • It is also possible to fast forward through the whole buffer to the 7:00pm point
  • Resume Channel A from point where it was previously paused

9:00pm

  • Current seek point in buffer is playing what was on Channel A at 5:00pm
  • It is possible to rewind to 4:00pm (1 hour seek-back buffer)

Scenario 2

1:00pm

  • Begin playing Channel A
  • Switch to Channel B

2:30pm

  • Channel B can rewind to 1:30pm (1 hour seek-back buffer)
  • Channel A can also rewind to 1:30pm (1 hour seek-back buffer, 2 hour inactivity timeout)
  • Continue watching Channel B

5:00pm

  • Channel B can rewind to 4:00pm (1 hour seek-back buffer)
  • There is no longer a buffer for Channel B (it hasn't been viewed in over 2 hours and timed out)

Scenario 3

1:00pm

  • Begin playing Channel A
  • Close app

2:30pm

  • Open app
  • Channel A is showing live content
  • It is possible to rewind to 1:30pm (1 hour seek-back buffer)
  • Close app

4:30pm

  • Open app
  • Channel A is showing the guide
  • Choose Channel A
  • It is playing live content and it is not possible to rewind (it hadn't been viewed in 2 hours and timed out)

Scenario 4

1:00pm

  • Begin playing Channel A
  • Switch to Channel B

2:00pm

  • Channel B is playing live content and can rewind to 1:00pm
  • Channel A is also playing live content and could be rewound to 1:00pm
  • Pause Channel B
  • Switch to Channel A
  • Close app

3:00pm

  • Open app
  • Channel A is playing live content and can rewind to 2:00pm
  • Channel B is paused at 2:00pm and can be fast-forwarded to 3:00pm or rewound to 1:00pm (1 hour seek-back buffer)
  • Continue watching Channel A

5:00pm

  • Channel A is playing live content and can rewind to 4:00pm
  • The buffer for Channel B has been closed because it was in the background for 2 hours (even though it was paused)
#2

Apple does not allow apps to run in the background. So as soon as you leave the app, we get disconnected from the HDHR and the buffer is lost.

#3

However, the app being closed or the channel being changed doesn't necessarily mean that the DVR server needs to clear the buffer it has written. Pausing the channel, closing the app, and then reopening the app to find it paused at the same point you left it could be as trivial as getting playback information from the server and setting the client-side buffer to the correct point.

#4

There is no buffer on the DVR Server for live tv.

#5

Not yet, that is. :wink:

(Although I cant speak to future features, this is one I would surely like. One of the things I miss about Tvheadend was having the buffer on the server. That would help alleviate the rather short buffer that comes from having it on the client device. Also, a server-based buffer would open up the option for additional features, like PIP and the like.)

#6

If the stream is being transcoded, there absolutely is:

admin@raspberrypi:~ $ ls -lAh dvr/Streaming/ch1425-dANY-ip192.168.29.137/ | head
total 89M
-rw-r--r-- 1 admin admin  871K Dec 15 02:06 stream100.ts
-rw-r--r-- 1 admin admin  590K Dec 15 02:06 stream101.ts
-rw-r--r-- 1 admin admin  340K Dec 15 02:06 stream102.ts
-rw-r--r-- 1 admin admin  804K Dec 15 02:06 stream103.ts
-rw-r--r-- 1 admin admin  215K Dec 15 02:06 stream104.ts
-rw-r--r-- 1 admin admin  830K Dec 15 02:06 stream105.ts
-rw-r--r-- 1 admin admin  192K Dec 15 02:06 stream106.ts
-rw-r--r-- 1 admin admin  758K Dec 15 02:06 stream107.ts
-rw-r--r-- 1 admin admin  662K Dec 15 02:06 stream108.ts

And there's realistically no reason that non-transcoded feeds couldn't be cached. And non-transcoded TVE streams even have a rolling cache:

admin@raspberrypi:~ $ ls -lAh dvr/Streaming/channels-cache-961861068/
total 5.8M
-rw-r--r-- 1 admin admin 785K Dec 15 02:10 1242caa63db352de81c2efb431546916bfc917e6cea4bd152181a8a0fc95271a
-rw-r--r-- 1 admin admin  296 Dec 15 02:10 .1242caa63db352de81c2efb431546916bfc917e6cea4bd152181a8a0fc95271a.completed
-rw-r--r-- 1 admin admin 500K Dec 15 02:10 1337c8c733b34c7d5aeb545b566f2223c9054a9db3e5aa7d1561c501dcd048a4
-rw-r--r-- 1 admin admin  258 Dec 15 02:10 .1337c8c733b34c7d5aeb545b566f2223c9054a9db3e5aa7d1561c501dcd048a4.completed
-rw-r--r-- 1 admin admin  77K Dec 15 02:10 18472a8c120a71ab761d1f8f8fb1054c003c0ba7565fd49cf0d5b32d1a7a6ca1
-rw-r--r-- 1 admin admin  258 Dec 15 02:10 .18472a8c120a71ab761d1f8f8fb1054c003c0ba7565fd49cf0d5b32d1a7a6ca1.completed
-rw-r--r-- 1 admin admin 803K Dec 15 02:10 1a0058c7451a20d80a67ad462c9ef80a6046c1a6b23de98c764ac63d6e02dafe
-rw-r--r-- 1 admin admin  296 Dec 15 02:10 .1a0058c7451a20d80a67ad462c9ef80a6046c1a6b23de98c764ac63d6e02dafe.completed
-rw-r--r-- 1 admin admin 500K Dec 15 02:10 511adb8aa5c17364bc5c47e8586553d369ec8cb3ab7ebebc81a22e97412bee7e
-rw-r--r-- 1 admin admin  258 Dec 15 02:10 .511adb8aa5c17364bc5c47e8586553d369ec8cb3ab7ebebc81a22e97412bee7e.completed
-rw-r--r-- 1 admin admin 779K Dec 15 02:10 9811a9ad0520cc77da221c0dbe3afebde2214f28d303ee1622681a9247697a4e
-rw-r--r-- 1 admin admin  296 Dec 15 02:10 .9811a9ad0520cc77da221c0dbe3afebde2214f28d303ee1622681a9247697a4e.completed
-rw-r--r-- 1 admin admin 818K Dec 15 02:10 b5a9d590ab9cb777a9dec96769957fd881dab968ac2270d4149def1173141ea2
-rw-r--r-- 1 admin admin  296 Dec 15 02:10 .b5a9d590ab9cb777a9dec96769957fd881dab968ac2270d4149def1173141ea2.completed
-rw-r--r-- 1 admin admin 791K Dec 15 02:10 ca3413821fd4c01ef7542098f45ce16741ba3ba53e6e3beb6e601e77f2603ef1
-rw-r--r-- 1 admin admin  296 Dec 15 02:10 .ca3413821fd4c01ef7542098f45ce16741ba3ba53e6e3beb6e601e77f2603ef1.completed
-rw-r--r-- 1 admin admin 806K Dec 15 02:10 d053b100f7b777159af8fef13e0e952076e41d88fcecb7d0fd989addd8dce103
-rw-r--r-- 1 admin admin  296 Dec 15 02:10 .d053b100f7b777159af8fef13e0e952076e41d88fcecb7d0fd989addd8dce103.completed
admin@raspberrypi:~ $ file dvr/Streaming/channels-cache-961861068/d2ba7f188a93d3d452e79babdd321c38ac21a647d5bd7722b99c14a2bbe97c32
dvr/Streaming/channels-cache-961861068/d2ba7f188a93d3d452e79babdd321c38ac21a647d5bd7722b99c14a2bbe97c32: MPEG transport stream data
admin@raspberrypi:~ $ cat dvr/Streaming/channels-cache-961861068/.d2ba7f188a93d3d452e79babdd321c38ac21a647d5bd7722b99c14a2bbe97c32.completed
23:https://x-viacom-stgec.uplynk.com/ausw/slices/bdb/[redacted]/G0000000D.ts?[redacted]
#7

For regular streams, the cache is small. The buffer that you see in the app and use to rw live shows is on the client.

1 Like
#8

Right, but thereā€™s already code that can write the entire cache of a live stream (when itā€™s being transcoded), and so now Iā€™m making a feature request that just makes that cache less ephemeral. This app lets you stream and record, Iā€™m proposing they be put together.

2 Likes
#9

Been hoping for more than one buffer for a long time... :grin:

I sure hope @racameron knows something we don't :crossed_fingers: