home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
Submit: code patches (MediaPortal/TV-Server/etc.)
Timeshifting in a single looping .ts file
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="dvdfreak" data-source="post: 712138" data-attributes="member: 21313"><p>OK, this is not the case in <strong>For The Record</strong>. Here, every client gets his own file, much easier, especially when clients start to zap around. They own the file/rtsp, so they can zap as much they want.</p><p></p><p></p><p>If the .lock file is written by the client the moment it pauses, I don't see the problem. In normal cases, the server has plenty of time to detect the file. Even if your live-point is really that hot on the heels of the client, it should be OK since there's a safety margin of a few seconds -- again plenty of time for the .lock file to be detected. When the client resumes playback it deletes the .lock file again.</p><p></p><p></p><p>The same comment goes for the current implementation, no? If a client is at the beginning of a file with .tsbuffer, and skips back? Same problem... With .tshift you could leave a buffer so you won't write exactly up to the pause-point, but stop -- say 5 minutes-- before you reach it (if possible).</p></blockquote><p></p>
[QUOTE="dvdfreak, post: 712138, member: 21313"] OK, this is not the case in [b]For The Record[/b]. Here, every client gets his own file, much easier, especially when clients start to zap around. They own the file/rtsp, so they can zap as much they want. If the .lock file is written by the client the moment it pauses, I don't see the problem. In normal cases, the server has plenty of time to detect the file. Even if your live-point is really that hot on the heels of the client, it should be OK since there's a safety margin of a few seconds -- again plenty of time for the .lock file to be detected. When the client resumes playback it deletes the .lock file again. The same comment goes for the current implementation, no? If a client is at the beginning of a file with .tsbuffer, and skips back? Same problem... With .tshift you could leave a buffer so you won't write exactly up to the pause-point, but stop -- say 5 minutes-- before you reach it (if possible). [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
Submit: code patches (MediaPortal/TV-Server/etc.)
Timeshifting in a single looping .ts file
Contact us
RSS
Top
Bottom