Timeshifting shows different channels (1 Viewer)

[josu]

Hello all,

strange behaviour since the last svns:

Try out:
1. switch some different channels in live-tv
2. then switch to fullscreen
3. play backward to the begin of timeshifting
4. and wonder

You see all switched channels on the last channel

Can anyone confirm this ??

 

[joboehl]

josu,

This one is by design. In TV Server, timeshift buffer doesn't get cleared when a channel change occurs.

That's strange depending from what SW you come from (even TVengine2), but it has it's advantages in the long run and it allows other clients running over the same timeshift file to continue to run.

There are suggestions to mimic the old behavior (like skip back back to last channel change), but they will probably not happen in the first stable release.

 

[josu]

joboehl,

but this design makes problems with the channel-change-remote-effects, which we have discussed in irc.

When both clients are on the same channel, an d you change the channel at the client, who was at first on this channel, the other client changed, too. And this is not good.
But real he doesnt change, he jumps only to the wrong point in the timeshift-file.

I cannot write c#, I ve only learned Z80 and fortran, in selfstudy databases and VB6. But I would organize the different ts-files in another way:

e.g.

card1.satx.tp2.chan34.client3.ts

The server-client I would transform to a real tcp-client over loopback-interface.

So you have a really good distinction and you can make a correct allocation to the clients. And you have no problems with recordings and timeshift.

Perhaps you and the devs can think over a redisign. It seems be possible, to manage the complete ts-switching in the database.

But the momentary condition is not good. I dont know, why nobody answer me in my thread


Please play a little with the same-channel-problem. You will see, thats a real problem.

I think, all problems in forum with recordings, timeshifting and my problem are away by a redisign

We see us today in irc

 

[joboehl]

If I understand correctly, ever client would have it's own timeshift buffer, is that it?

I think the overhead of this would be too high (2 writes + 2 reads for a 2 client config) and would not solve the problem completly. When client2 get's at the end it's timeshift it will stop anyway, since tuner is changed to a different channel and timeshif file is not updated anymore. Am I right in my assumptions?

Latest SVNs should work close to this. If no other card available, then the "slave" client will stop on a channel change. This way there is no "remote" effect, but someone might be cutt-off on what they are seeing.

 

[josu]

Yes, I thought, if every client has its own ts, also the recorder, then you have no
influence between the clients and the recorder.
And the client on the server over tcp-loopback.


quote: I think the overhead of this would be too high (2 writes + 2 reads for a 2 client config) and would not solve the problem completly. When client2 get's at the end it's timeshift it will stop anyway, since tuner is changed to a different channel and timeshif file is not updated anymore. Am I right in my assumptions?

I dont know, how the streamserver works, but I think, if every client get its own stream, it must run (unicast)

 

[joboehl]

Just a side note: reviewing your first post, you hould not jump to the beggining of the stream when switching to full screen. The design is to keep al the info in the timeshinf buffer, but different clients can be positioned in different points of the stream.

So in your case, when swithing to fullscreen you should continue from the same point, but if you deliberate ask to skipp back to the beggining of the stream, then you should see all channel changes in the stream.

This fullscreen issue still happens to you?

 

[josu]

Just a side note: reviewing your first post, you hould not jump to the beggining of the stream when switching to full screen. The design is to keep al the info in the timeshinf buffer, but different clients can be positioned in different points of the stream.

So in your case, when swithing to fullscreen you should continue from the same point, but if you deliberate ask to skipp back to the beggining of the stream, then you should see all channel changes in the stream.

This fullscreen issue still happens to you?

hi joboehl,
I think, I have not understand your question really:sorry:

But if I switches 10 channels successively, and then I go to fullscreen and play back to the beginning, I see successively all 10 channels.

Quote:The design is to keep al the info in the timeshinf buffer, but different clients can be positioned in different points of the stream.
That is the other problem, the right position dont work

 

[ronilse]

Hi,
If you on the 2. client grab the same stream as you have switched channels with (first client), it will start @ timeshift beginning & you will see all the channel switches, but you can easily on 2. client seek to end & have the same almost synchronous stream on both clients (2. client start on ts buffer start & not on live point could be a bug, have to ask Frodo about it)

Regards
Roy

 

[josu]

Hi,
(2. client start on ts buffer start & not on live point could be a bug, have to ask Frodo about it)

Regards
Roy

Hi, ronilse,
thats right, he starts not on the livepoint.

 

[josu]

live-point is now correct svn12998
to frodo and all other in this thread