HTPS low trought put

[jonudewux]

If pvr and tvh are on different machines on same lan network, it can reach speed event play sd video recording.
If pvr and tvheadend server are runing on same machine, even fullhd video recordings are ok.
Timings how 32768 bytes chunks are requested prom pvr in both cases,
different machines - same macine:
37442 us 425 us
46126 us 419 us
37247 us 496 us
40757 us 546 us
43468 us 571 us
38209 us 520 us
47185 us 508 us
37270 us 363 us
38453 us 419 us
39842 us 405 us
51217 us 363 us
Maybe as a back-up http can be used.

[jonudewux]

Seems that simplify 241d8ac "CHTSPVFS drastically by removing the intermediate" broke htps on a little bit slower network.

[ManOki]

I observed the same issue at my setup now.

I have tvheadend 4.2.4-23~gceaf330cb~stretch from bintray deb https://dl.bintray.com/tvheadend/deb stretch stable-4.2 running on a x86_64 server and kodi 2:17.5-1~stretch with pvr.hts 3.4.27-1~stretch running on a raspberry pi.

I don't know at what time this issue first occured, but i just noticed it only recently, not 9 months ago. I update tvheadend and kodi on regular basis.

@jonudewux i saw your answer in the tvheadend forum as well. Is there any other way to remove that CHTSPVFS buffer you mentioned, than using your commit, recompile and rebuild the whole pvs.hts binary?

Is this issue related to kodi, pvr.hts or directly to tvheadend?

[Jalle19]

@FernetMenta are there any plans for VideoPlayer to "read ahead"? In my opinion it's a bit unfortunate that PVR clients would have to make their own buffer implementation just because Kodi insists on reading 32 KB at a time.

[FernetMenta]

@Jalle19 Yo are not correct in you assumptions. VP does not insist on 32KB. VP requests a packets from demuxer. If a PVR addons implements demuxer API, and I think hts does, it is on the addon how to read data and how to handle the process of demuxing.
Not sure what you mean with "read ahead" in this context.

[ksooo]

I think pvr.hts uses demuxer for live tv only. We are talking about playback of recordings here which is implemented using vfs api.

[FernetMenta]

Addons can chose to handle reading the stream by themselves of delegete to Kodi core. Depending on the type of source Kodi core choses an appropriate method for buffering and block size for reading. Implementation of IFile can i.e. override GetChunkSize.

[Jalle19]

I should have mentioned that in this case we're talking about ReadRecordedStream() and related methods. How would the addon control how Kodi does buffering in this case?

[FernetMenta]

Why do you implement ReadRecordedStream() if you don't want to handle stream handling yourself? This method is for custom protocols (LAN) between the client and the backend. vnsi for example does no buffering because skipping, searching etc. is much faster without buffering. The 8 sec demuxer queue is enough. This interface is not suited for WAN. If you have requirements for buffering, you should use a standard streaming protocol and pass the url to Kodi.

[Jalle19]

@FernetMenta the original reasoning behind it was that Kodi couldn't handle HTTP streams for in-progress recordings (playback would stop once the "end" was reached). If this is no longer an issue then we could easily switch back to using HTTP instead of the custom VFS we currently have.

[FernetMenta]

ffmpeg demuxer has always been able to handle live http streams. It won't display correct remaining time because playing time is evaluated only at start.
vnsi handles growing files and displays time corectly. Using HTTP on a LAN does not make any sense. I still don't understand your requirements for buffering. You don't need buffering on a LAN.

[Jalle19]

@FernetMenta were not talking about LAN here, these problems usually manifest only when streaming over WAN.

It has been able to handle live streams, sure, but if you start a recording that has been recording for 10 minutes, then try to skip 30 minutes forward, playback stops. Unless that has changed I'm reluctant to abandon the current VFS approach.

How does VNSI handle this if it uses HTTP?

[FernetMenta]

PVR API was designed for LAN, not WAN.

How does VNSI handle this if it uses HTTP?

VNSI (VDR network streaming interface) is a protocol by itself. Not designed for use in a WAN.

There are streaming protocols that work well on WAN. IMO recordings in progress via WAN is a silly use case. If you are not at home, don't watch a recording or TV (the P in PVR is for personal). Of course, there are always some who may find this a valid use case. Kodi provides the interfaces to implement this, but generic code for corner cases don't make sense.

[Jalle19]

I don't think arbitrarily limiting PVR to LAN is a good reason for not coming up with a solution for this. You might have a TV setup in your summer cottage that streams from your server at home, or a myriad of other valid use cases. Even bad wifi can be enough to cause the type of issues we're talking about here.

We used to have a buffer but it caused more problems than it solved so we ended up removing it. We could use HTTP like I said but I'm still not sure what happens when you try to skip past the "end" in a live recording?

[FernetMenta]

I don't think arbitrarily limiting PVR to LAN

you really mix up things here. not being designed for something is not limiting. you sound like somebody complaining about his car does not fly. of course it does not, it is a car and has not been designed to fly. PVR was designed for use within a LAN. it has been abused to work in a WAN and now you complain about the abuse.

Even bad wifi can be enough to cause the type of issues we're talking about here.

definitely not. VP has a demux buffer of 8 sec. I haven't had a single issue for vnsi that would proof your statement.

HTTP like I said but I'm still not sure what happens when you try to skip past the "end" in a live recording?

just try a http stream. I would expect it to behave like a local file: it stops if you seek past the end.

again: Kodi provides all the APIs you need to implement your use case. you can write an inputstream addon with demuxer that does not stop if you seek behind end. pvr streaming api will die anyway in favour of inputstream.

[Jalle19]

you really mix up things here. not being designed for something is not limiting. you sound like somebody complaining about his car does not fly. of course it does not, it is a car and has not been designed to fly. PVR was designed for use within a LAN. it has been abused to work in a WAN and now you complain about the abuse.

Most PVR addons use IP to communicate with the backend, which means people assume it will work over any IP connection as long as the bandwidth is sufficient. I think the main problem here is latency, which is why some people have issues over WAN links.

definitely not. VP has a demux buffer of 8 sec. I haven't had a single issue for vnsi that would proof your statement.

I'm guessing VNSI uses some kind of buffer or an alternative API between Kodi and the addon, otherwise you would definitely have noticed this issue too.

would expect it to behave like a local file: it stops if you seek past the end.

That is unacceptable, like I said this was the reason tvheadend (and subsequently this addon) implemented a poor man's VFS in the first place.

again: Kodi provides all the APIs you need to implement your use case. you can write an inputstream addon with demuxer that does not stop if you seek behind end. pvr streaming api will die anyway in favour of inputstream.

Indeed it does (the current code works, just not as efficiently as we would like) but it seems a bit unfair for addons to have to deal with buffering just because Kodi assumes something is on a LAN. I don't think it's worth changing anything on the addon side until the current API is removed when we'll have to come up with an alternative solution anyway.