[aegidius]

This might be nice, specially if (as is probably common) the server is low-powered and/or slow with network I/O, while the client has plenty of disk and I/O bandwidth (like, say an average Windows PC client with Raspberry Pi server). The server could still do recording, but volatile stuff like timeshift I/O could be kept off it. It might allow for faster skipping, too - sometimes it takes 5 seconds to skip back 7 with a round trip from client to TVHeadend.
(Moved from general support page, after it was pointed out that the PVR addon would implement this - but IMHO a worthwhile thing to do centrally if feasible as it would benefit all PVR's)

[rpcameron]

The current model of timeshifting on the server is done "centrally". What you are asking for is a local implementation, not a central one.

Also, the advantage of timeshifting on the server is that a single buffer is shared across clients for the same stream. While it may not be that other clients are streaming the same channel, they may be streaming a channel on the same mux. And since Tvheadend supports recording full muxes and filtering and streaming a particular service on that mux out, it is actually saving resources.

Also, I feel your example is a little backwards for most situations. The larger more powerful desktop-class machine is usually your tv/streaming server, and the low power/low memory devices such as the Raspberry Pi are usually the clients. (Smaller low power SBC devices like the Pi may make a decent server, but the Pi specifically does not because of its constrained and shared bus and limited memory. Other SBC devices like the Orange Pi/Banana Pi or Odroid series would make better servers as their bus architecture allows for greater throughput at similar prices/specs.)

[aegidius]

The current model of timeshifting on the server is done "centrally". What you are asking for is a local implementation, not a central one.
 

By centrally I meant in Kodi itself rather than decided by its various PVR client plugins. Sorry, bad choice of wording.

Other points taken - just wondering if an option warranted to timeshift on the client. I'd certainly use it in my setup, and I'm sure my setup is not unusual.

If TVH is indeed recording a full mux, then it's beating up the network even more than I thought! Is there a setting to control this in TVH? I can't find it at a quick look. It must be off, because if it was on the network traffic would add up to a lot more than 100Mb/s when watching one channel and recording another off a different mux. I do this all the time on an RPi server without a glitch.

[JiRo]

... And since Tvheadend supports recording full muxes ...

I do not think TVH supports recording of the full muxes. Can you explain it somehow?

[rpcameron]

... And since Tvheadend supports recording full muxes ...

I do not think TVH supports recording of the full muxes. Can you explain it somehow?

That's actually not quite true. What Tvheadend can do is selectively filter a mux. It works a bit like this:

Mux contains services A, B and C.
Client 1 wants to watch A.
Tvheadend tunes mux, and sets a filter so it only receives service A.
While client 1 is watching service A, client 2 wants to watch service C.
Tvheadend adjusts the filter on the mux, so now it is receiving services A and C.
Both clients 1 and 2 are watching separate channels, and only using a single tuner.

Other software (SiliconDust, I'm looking at you specifically) uses a separate physical tuner for each service, regardless of whether the requested services are on the same mux. For the Prime, this is understandable because of the decryption needed. For other models, it's simply because they don't want to do it that way. (The same reason they won't offer a grid-based EPG for their software/DVR service: they feel their way is better, so you don't get the option to choose.)

MythTV handles this a little differently—at least they used to. With MythTV you used to be able to create a "virtual" tuner that worked effectively as a filter on the mux, resulting in the same functionality.

[JiRo]

@rpcameron

Ok. We know how it works to record multiple services from one mux in Tvheadend.

It is important that we agree that Tvheadened can not record the entire mux. Claiming that yes, less experienced users could be misled.

[rpcameron]

@rpcameron

Ok. We know how it works to record multiple services from one mux in Tvheadend.

It is important that we agree that Tvheadened can not record the entire mux. Claiming that yes, less experienced users could be misled.

Just because it doesn't offer it by default does not mean it's not possible. Because of my personal use-case, I've tweaked some of Tvheadend frontend code for the version I use. My version actually bypasses the PID filtering of muxes and does actually stream and record the complete mux when requested. Therefore, it is certainly possible that Tvheadend can record the complete mux. (Also, note I mentioned the frontend is the code I tweaked, not any of Tvheadend's backend code. Program filtering on a mux is frontend code ...)

[JiRo]

I've tweaked some of Tvheadend frontend code...

It should be noted at the beginning of disscusion that this is possible on the basis of a non-standard (tweaked) TVH frontend. Otherwise, the inexperienced users are confused!

And can I ask in which format the whole mux is recording? And how is the recording of the whole mux set up and how to select a specific chanell during playback? Can you show some screenshots?

I'm interested in it because I needed to record the mux a few times. I have solved this by selecting all channels (services) in the EPG for the selected mux and the time interval via the TVH backend GUI. But that's a little complicated. 

[rpcameron]

I record with the pass profile, so the stream from the tuner is put into a single transport stream. You can then use VLC or whichever media player you like to select the different program streams from the recorded TS. My tuners are HDHomeRun tuners, so I've modified the tvhdhomerun_frontend.c file where tuning occurs to bypass filtering.

[benoire]

This might be nice, specially if (as is probably common) the server is low-powered and/or slow with network I/O, while the client has plenty of disk and I/O bandwidth (like, say an average Windows PC client with Raspberry Pi server). The server could still do recording, but volatile stuff like timeshift I/O could be kept off it. It might allow for faster skipping, too - sometimes it takes 5 seconds to skip back 7 with a round trip from client to TVHeadend.
(Moved from general support page, after it was pointed out that the PVR addon would implement this - but IMHO a worthwhile thing to do centrally if feasible as it would benefit all PVR's)

I'm going to slightly necro this thread; this would solve the issues of ffw/rw at higher speeds.  Currently using TVH on a 1gbe wired network I can get to x8 FFW before network latency affects seeking.  With the stream fed from TVH without it timeshifting, and the client timeshifting, this would reduce the latency to local standards which should allow up to x30 without hassle.