-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delayed start feature request #352
Comments
IMO it's up to the underlying operation system to control the proper startup of the different services and apps, not pvr.hts' job. |
I completely understand this. However, everything starts as expected. If tvheadend server needs 15s to start up and pvr.hts is trying to connect for 15s and gives errors, this should be handled by the application. I think. Maybe a delayed start feature is not even needed, connection delay after startup would do it as well. Am I the only one having this issue? Maybe tvheadend starts faster on other devices? |
Even on my raspi2 tvh does not need that long to start. Go and fix your system. ;-) |
pvr.hts expects always that Tvh is available - if not then it throws a warning (you can disable iirc). Kodi offers that function for NAS etc to wakeup for usage at access, because Kodi knows when it needs the data from the NAS not the OS. Same goes for the PVR part (I guess this is not an pvr.hts problem, more an pvr in general problem/feature) but currently there is no implementation. -edit- |
WOL is another use case, not what the OP is talking about. |
His OS WOL the server, then he needs an workaround/hack because Kodi can't handle the situation. So he ask for an workaround because Kodi is missing WOL at the pvr. From my perspective the software that knows the state and requires some server should manage the WOL like Kodi already is doing it for the media lib. |
I like the course of this discussion. In case the server and client are running on the same device there should be some state push from the server via tcp. Based on this state(nothing/busy/ready), pvr.hts would know what is going on on the server side. Would be interesting also for the WOL story, if I got you right. |
Oh then |
I completely agree that a proper handling is needed. Anyway, I'm on Tvheadend 4.3, fresh install. Previously, I was on 4.2. I never was on 4.0. A friend reports this issue as well. I do have 1400 DVB-S2 channels, maybe this is the reason. However, this should not lead to errors on the pvr.hts side. What I do not understand is why I get these errors also if I change the two timeout settings. Also that pvr.hts reports that it does not receive an appropriate answer and 1 second later it loads all channels implies that pvr.hts is probing the server. Just before it is ready it gets half an answer, therefore reports wrong response. For the next probing everything works. I have no glue how pvr.hts is handling the connection to the server, I just tell what I see from the error messages popping up. And again, this is a minor problem, after kodi started it takes 10s and pvr.hts loads the channels. |
On my hardware I get two error messages after every restart. The first one tells me that pvr.hts was not able to connect to the tvheadend server. The second one about 5 seconds later tells me that pvr.hts did not receive the appropriate response. I guess this is because the tvheadend server needs time to start up and pvr.hts is all the time trying to reach it.
Playing with the timeout settings did not change anything.
I was wondering if a delayed start feature would be helpful here. Or an option to avoid those messages somehow? What do you think? This is a minor thing but after using kodi and pvr.hts for two years now I was thinking it would be really nice to have.
The text was updated successfully, but these errors were encountered: