Load channel settings properly when <cacheindvdplayer> is disabled #4333
Conversation
|
@FernetMenta I removed the last commit (the one you commented on, naturally Github lost it...). Did you find the time to look at the rest of it? It would be nice to see this make it into Gotham, without this pvr.cacheindvdplayer is all but useless. |
|
I remember lots of trouble with those functions until we got it work for almost all scenarios. I assess the risk that something may break as relatively high. IMO we should rather prevent pvr.cacheindvdplayer from being disabled because it forces the system into an unstable state in which it is not supposed to run. When an audio stream is started AE fills the various buffers which in sum hold up to approximately 0.8 seconds of audio, If you reduce pvr caching from the default values those buffers never fill. It may work somehow but this is not the stable state. Apart from this I agree that load/save of channel settings needs rework. G+1 |
|
The only trouble has been that loading the settings has been done in the most non-obvious place available (HandlePlaySpeed). With these changes it is much more predictable. I'd rather not see the advanced setting removed, it speeds up zapping considerably. |
|
We have told you multiple times that your attempts to speed up channel switching sacrifice behavior we have implemented for good reasons. Fast channel changing is worth nothing if audio stalls some time later. Your changes my work somehow on you system but for sure won't work on every system. Removing the caching is no option. |
|
These changes don't remove the caching option (I closed that PR yesterday precisely because like you say it may have unintended consequences). I'm trying to make an optional (advanced) setting which disables it actually work, that's all. |
|
Anyway, if these changes don't cut it, do you have any suggestions on alternative ways of doing it? |
|
I did not say the changes in this pr are wrong. They are reasonable and should be discussed G+1 because the risk that something breaks is high. |
|
Okay, I can live with that. If there were a less intrusive way to make this work correctly I'd go for that, but it seems it's not possible. |
|
@opdenkamp any comment on this? |
|
could you rebase ? dont work with actual git master |
|
been away all week end and haven't had time to look at this yet @piotrasd please rebase yourself if you like to test this and don't post about it on github. hundreds of people get an email about this. |
|
@piotrasd it's rebased now, I'm in the process of build testing it but at a glance it seems fine. |
instead of passing the call along to PVRClients. Also call the methods in the appropriate places (OpenLiveStream, CloseLiveStream and PerformChannelSwitch)
|
Rebased again (didn't have the latest local copy), don't know why the merge button is still gray though. |
|
Looks like you forgot to push or rebased against the wrong tree. |
|
@FernetMenta or me needs to review this properly and +1 it before this is allowed to go in |
|
@t-nelson should be fixed now, I rebased the wrong local branch and pushed that. No wonder the light didn't turn green. @opdenkamp of course |
|
Yeep, works great !!! thanks. |
| @@ -5761,10 +5758,6 @@ void CApplication::SaveCurrentFileSettings() | |||
| dbs.Close(); | |||
| } | |||
| } | |||
| else if (m_itemCurrentFile->IsPVRChannel()) | |||
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
Replaced by #4783 |
MartijnKaijser
modified the milestones:
Abandoned, obsolete or superseeded,
Pending for inclusion
There is currently a bug in XBMC which causes channel settings to not be loaded at all when pvr.cacheindvdplayer is disabled. The setting is used to dramatically speed up the time it takes to switch channels on backends with an internal demuxer. The problem is that the call to load the settings is done in a block that is never reached when the setting is disabled.
Because standard files and PVR channels work quite differently I've opted to contain loading/saving of channel settings in PVRManager. Currently they're loaded in Open/CloseLiveStream() and PerformChannelSwitch(). They were previously loaded in DVDPlayer and sometimes stored in Application in addition to whenever the current audio/video settings were changed.
I've also changed the Save/Load methods to take the channel in question as a parameter, this way it is easier to put the call in the proper location. It also alleviates the need to defer to PVRClients to handle the logic.
@opdenkamp @FernetMenta would be nice if you could chip in
@margro can you check for regressions with some backend other than tvheadend/vdr?