rocky4546
commented
1 year ago This seems like a great idea, but has a few gotchas that need to be worked through. Thought I would lay out some thoughts on the topic.
Good news is that there is a separate process per stream and a single multi-threaded process containing all client requests, so we can tie multiple client threads to a single stream process, fairly easily.
It would help with providers that do not like multiple connections from a single IP.
Also, a good thing would be the stupid kodi pvr-tvh app that disconnects and reconnects every time there is a 10 second delay between incoming stream segments. It would basically keep feeding the segments to the new client; although, how we restart the second client stream could easily cause some deja vu replaying of segments when buffered or missing segments, if not buffering.
Also, we need to address the VOD channels. These provide the entire movie at one time to the client. Should we in this case start a separate provider stream to start the movie from the beginning, or start at some point in the middle based on the current client connection. My thought currently is to use separate process streams.
The biggest issues is the operating system forking errors. There is an operating system condition with python that the new forked process does not establish communication pipes like it should. Right now, when the pipes fail to establish, the stream process is terminated and restarted. Then, it is checked again to see if the pipe has formed correctly. This actually happens quite often.
So, in summary, we need to:
- Determine how to handle the startup of the second stream associated with buffering. We could just send the current stream (no buffering), which for the pvr-tvh issue would lose at least one segment. Or, we could send what we have currently for backup and that would give the stream some buffering, which for pvr-tvh would cause a deja vu condition.
- Determine how to handle VOD. VOD is special case, in that, the entire movie is provided at the start and normally it is the client that squelches the data rate (not Cabernet). If we use the same provider process, it would make sense to not start at the beginning (which may not be what is expected). Or, provide a new stream process for each VOD and do not mux the stream together. That way the streams would all play from the beginning.
- Determine how to handle the case when a forked process fails to start correctly and the pipes between processes do not work. Currently the process is terminated, but if multiple clients are connected to the process, then it does not make sense to restart the process.
As for sending video back to the client, there are two groups on that. One is to terminate the connection when too many tuners are in use. The other is to send something that makes it looks like a tuner is available to the media server. We are currently doing what TVH does, which make it consistent with our logical processes. That means we termination of the connection when too many connections are in use. This helps a ton when starting a recording and some of the tuners just need to timeout. TVH will go through a timeout and then retry the connection to see if the connection will work. This also works great when the provider is giving connection refused and needs to go through a timeout before it will work correctly. I do not see any advantage for displaying a video on the screen, considering all the negatives.
It would be nice if you added the ability to split an incoming stream to multiple clients. xTeVe does this. Here is an example.
You pull in one stream from Fox News then 5 TVs in your home can all watch Fox News at the same time. So you are only pulling 1 copy of the stream, not 5.
Also xTeVe will send a video image to clients if there are no more "tuners" available so they don't just get weird errors because there are no more tuners available. Instead on the client they see a screen saying "Sorry. There are no more free tuners available for this channel. Please try this channel later."
I personally think the xTeVe web interface stinks and it has not been updated in over a year.