Skip to content
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

Open
riegaz opened this issue Jan 16, 2018 · 9 comments
Open

Delayed start feature request #352

riegaz opened this issue Jan 16, 2018 · 9 comments
Labels

Comments

@riegaz
Copy link

riegaz commented Jan 16, 2018

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.

@ksooo
Copy link
Member

ksooo commented Jan 16, 2018

IMO it's up to the underlying operation system to control the proper startup of the different services and apps, not pvr.hts' job.

@riegaz
Copy link
Author

riegaz commented Jan 16, 2018

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?

@ksooo
Copy link
Member

ksooo commented Jan 16, 2018

Even on my raspi2 tvh does not need that long to start. Go and fix your system. ;-)

@CvH
Copy link

CvH commented Jan 16, 2018

pvr.hts expects always that Tvh is available - if not then it throws a warning (you can disable iirc).
It is not aware about the WOL case. WOL of an TV Server isn't really something the OS should handle as you can only do it with ugly workarounds like delaying the start of kodi till the server is available or something. Also you have to start the TV server with/before Kodi what is likely unwanted. If you watch 10h tv shows or something the tv server hasn't to run. This is currently not really doable.

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-
pvr.vdr.vnsi has some basic Implementation of WOL support https://github.com/kodi-pvr/pvr.vdr.vnsi/blob/Krypton/pvr.vdr.vnsi/resources/settings.xml

@ksooo
Copy link
Member

ksooo commented Jan 16, 2018

WOL is another use case, not what the OP is talking about.

@CvH
Copy link

CvH commented Jan 16, 2018

His OS WOL the server, then he needs an workaround/hack because Kodi can't handle the situation.
If Kodi would be aware that the server is currently waking up due WOL he won't need it.

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.

@riegaz
Copy link
Author

riegaz commented Jan 17, 2018

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.

@CvH
Copy link

CvH commented Jan 17, 2018

Oh then fix your system is not that wrong ;) Since Tvheadend 4.2 the start-up-times have reduced dramatically, if you updated from 4.0 -> 4.2 you won't get that "fix" (afaik the db structure isn't upgraded if you update 4.0->4.2).
Your case is basically the same as the WOL case just that you won't need to wake up the server - just wait for him. A proper handling of this situations would be nice regardless.

@riegaz
Copy link
Author

riegaz commented Jan 17, 2018

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.

@ksooo ksooo added the Feature label Jun 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants