Reply to thread

Message

<blockquote data-quote="arion_p" data-source="post: 712163" data-attributes="member: 45945">That defeats a great feature of TVServer: switching seats. In MP/TVE you can pause live TV in one client (living room) then go to the other client (bedroom) tune to the same channel, skip back to the position you where watching and pause. Then stop live TV in living room. Finally got to bedroom to resume your watching. With the new feature we are planning this is going to be a lot easier: Park your live TV session in living room and turn off htpc, then go to bedroom turn on htpc and resume your parked live TV session where you left it.If the client is far behind live position, it can be a problem. Imagine server write position is 16kb behind client's read position. When the client pauses it will write the lock file, but by the time it does server may have already written beyond client's read position. This can also happen even without the client pausing. If the client reads in largish blocks the read position may fall behind the server's write position. Also if client's clock is not accurate, it may play slower than real time and the 16kb leeway will soon vanish. When that happens it is better if server stops writing and live data is lost than to have the client suddenly seeing live data.</blockquote>

[QUOTE="arion_p, post: 712163, member: 45945"] That defeats a great feature of TVServer: switching seats. In MP/TVE you can pause live TV in one client (living room) then go to the other client (bedroom) tune to the same channel, skip back to the position you where watching and pause. Then stop live TV in living room. Finally got to bedroom to resume your watching. With the new feature we are planning this is going to be a lot easier: Park your live TV session in living room and turn off htpc, then go to bedroom turn on htpc and resume your parked live TV session where you left it. If the client is far behind live position, it can be a problem. Imagine server write position is 16kb behind client's read position. When the client pauses it will write the lock file, but by the time it does server may have already written beyond client's read position. This can also happen even without the client pausing. If the client reads in largish blocks the read position may fall behind the server's write position. Also if client's clock is not accurate, it may play slower than real time and the 16kb leeway will soon vanish. When that happens it is better if server stops writing and live data is lost than to have the client suddenly seeing live data. [/QUOTE]

Verification