[FernetMenta]

Is that really a reasonable scenario to prepare for? And like you said yourself, if you consume more audio packets than you "produce" it is only a matter of time until you're screwed anyway. An initial buffering only delays the inevitable. Do I have this all backwards or what?

As I said before: we want a mode which can sync the clock to the cache level. Then the system can fill the cache by slowing down play speed.

[negge]

Perhaps, but there really should be a better documented way of disabling the buffering if we have to keep it. I only learned of the advanced setting when digging through the code, and its name doesn't reflect that it has anything to do with PVR playback.

What about the demuxer changes? Do you know anything about that part of the code?

---

As I said before: we want a mode which can sync the clock to the cache level. Then the system can fill the cache by slowing down play speed.

Ideally we should then start out with an empty buffer and start caching (thus pausing playback) once it's actually needed. This way we'd get the best of both world's - quick channel switching and pause instead of glitching when we don't have enough data.

[FernetMenta]

What about the demuxer changes? Do you know anything about that part of the code?

As I already tried to explain on github: you can't reuse a decoder for a different stream. Opening a new demuxer is fast and causes no delay. you see an "improvement" because you feed the new stream into the old decoder without flush and waiting for a key frame. That won't work for all cases.

[negge]

As I already tried to explain on github: you can't reuse a decoder for a different stream.

The fact that it works just fine for me seems to contradict this. Why exactly can it not be done?

Opening a new demuxer is fast and causes no delay. you see an "improvement" because you feed the new stream into the old decoder without flush and waiting for a key frame. That won't work for all cases.

Could you give an example of these cases? I've zapped channels probably over a hundred times so far with this code and haven't noticed any problems yet.

What about the two first commits then? Trying to find something that has been right here :-D

---

By the way, doesn't tvheadend always send an I-frame as the first frame when a subscription starts? If so it should be safe to start playing immediately?

[produno]

Just to add my input.

Im using Margros latest release of the gotham build.

Using the advanced setting in the first post, the channels are slightly quicker to change with no issues with audio etc. BUT my screen is set to refresh to the current playing media and when it does this it has to buffer, which takes 2-4 seconds. Before I used the advanced setting it probably took an extra second or so to change channel but no wait when refreshing.

So in my case its actually slower. If their is a way to get the screen to refresh upon channel change then that would wield better results. Though for some reason, it will change channel, play for about 5 seconds then it will refresh.

Im using Next pvr as a backend if that makes a difference.

[negge]

This does not concern any other backends than the one in the thread title.

[opdenkamp]

your proposed pr definitely does concern other add-ons. like i said before, your changes may work fine for your specific setup and dvb network, but they will make things worse for others.

[produno]

This does not concern any other backends than the one in the thread title.

Yeah sorry, i realised that after.

But as Opdenkamp says, if you change the code then all backends will be effected. In my case for the worst.

[negge]

your proposed pr definitely does concern other add-ons. like i said before, your changes may work fine for your specific setup and dvb network, but they will make things worse for others.

I realize the caching related changes affects everyone, though the other changes are supposed to be localized to only such addons that have their own demuxer. Furthermore, "this won't work" doesn't really help me in any way.

At the very least we should figure out where to load the channel settings so that it works even when caching is disabled through advancedsettings. If we'd get that fixed the whole commit that touches caching could be scratched since the effect would be achievable without code changes for those who want it.

[FernetMenta]

the reason for settings being loaded and stored like that is for channel switches, and when you don't have streams yet after the call to OpenLiveStream(). it will not select the correct stream in that case.

Now that we trigger OpenDefaultStreams on a stream change, it should work loading channels settings right after channel switch and of course old channel settings have been stored.

[negge]

There's still some issues with the new code, at the moment I'm seeing this behavior:

- stored channel settings always get loaded
- subtitles are togglable and changeable from the OSD dialog but only sometimes when pressing the "change subtitle" button. It works sometimes and sometimes not, do you know what code affects this? I thought the "subtitle switch button" simply looped through the available streams but it seems that's not the case (since I can change them just fine from the subtitle dialog).

[opdenkamp]

Furthermore, "this won't work" doesn't really help me in any way.

both fernetmenta and i explained it to you already?

[negge]

both fernetmenta and i explained it to you already?

You have adequately explained the reasoning behind the caching mechanism, but I still don't understand what's wrong with reusing the demuxer or if there's anything wrong with the first two commits?

[elupus]

demuxer needs reset on channel changes. It will have wrong timestamps/wrong metadata of stream like width/height and others thing. And as mentioned demuxer reset/recreate should be quick, if it isn't that is what should be solved.

[negge]

demuxer needs reset on channel changes. It will have wrong timestamps/wrong metadata of stream like width/height and others thing. And as mentioned demuxer reset/recreate should be quick, if it isn't that is what should be solved.

Width and height seems to be taken into account just fine even with these changes, as to codec changes and so on. The current program time is also updated like it should.

I guess the biggest slowdown comes from the caching, another part is the unnecessary call to RequestStreams() that I removed (it was always done twice when switching channels).

I guess I should upload comparable logs so you guys can see what has been cut from the process.