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 2
Plugin Development
Trakt.tv LiveTV scrobble Development help request.
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="Alberto83" data-source="post: 1223298" data-attributes="member: 128278"><p>I haven't the code here but i'll post the relevant part when i come back home.</p><p></p><p>It basically consists in setting a thread.timer to fire up every "tvhandler.nextprogram.starttime" and then resets it with the "tvhandler.nextprogram.starttime" again if the callback function is fired (and the previous tvhandler.nextprogram becomes the tvhandler.currentprogram) or when there's a new tuning event (and thus a new nexprogram on a new channel).</p><p>The callback function of the timer just creates a tscontext with the new program and adds it to the <em>timeshiftmediaitem.TimeshiftContexes</em> manually, without removing the old one (since we're in the same channel). I basically never remove tscontexts but keep adding them and that's why the recycler is needed to remove old entries somehow (or tombestone them). The tscontext.tuneintime is set to datetime.now every time i have to create a new tscontext (so every time a new channel is tuned, or the callback function runs). This way i have a timeshift context is effectively a timeline of the timeshift.</p><p></p><p>It's perfectly safe since if, for a moment, we forget that the TS file is "circular", everything before "NOW" in the timeline cannot be changed. It's there and there stays for the whole lifetime of the stream. When the stream is over, we don't need it anymore.</p><p>Also the timer for the next program is safe, because the only thing that could alter that timer is a new tuning event on that stream where we need to reset the timer with a different nextprogram.starttime. Zapping isn't a big deal, we're not tuning while zapping.</p><p>Since i'm using the tvhandler.currentprogram and tvhandler.nexprogram this isn't affected by pausing the tsreader.</p><p>I don't know if i explained that well, i'll post the code.</p><p></p><p>When i thought of doing it "server side" i was thinking more of creating the entire TSContext logic on the server (per stream, like now on my solution) and return the relevant portion to the client every time we use the timeshift feature. Since the server, and only the server, can write the stream, it seemed logical to me that it should be the only one that should create and handle this sort of "timeline" and recycle old programs.</p><p>Moreover, this would open up to sharing streams (and it's timeline) to all clients that connect to that stream. (EDIT: i'm more thinking about placeshifting than really sharing the stream)</p><p>Instead of embed those properties in the TS file which seems too complex, what about storing the whole timeline data on the server memory and ask for it from the client based on the tsreader position? This would make them indipendent from the tswriter, right?</p></blockquote><p></p>
[QUOTE="Alberto83, post: 1223298, member: 128278"] I haven't the code here but i'll post the relevant part when i come back home. It basically consists in setting a thread.timer to fire up every "tvhandler.nextprogram.starttime" and then resets it with the "tvhandler.nextprogram.starttime" again if the callback function is fired (and the previous tvhandler.nextprogram becomes the tvhandler.currentprogram) or when there's a new tuning event (and thus a new nexprogram on a new channel). The callback function of the timer just creates a tscontext with the new program and adds it to the [I]timeshiftmediaitem.TimeshiftContexes[/I] manually, without removing the old one (since we're in the same channel). I basically never remove tscontexts but keep adding them and that's why the recycler is needed to remove old entries somehow (or tombestone them). The tscontext.tuneintime is set to datetime.now every time i have to create a new tscontext (so every time a new channel is tuned, or the callback function runs). This way i have a timeshift context is effectively a timeline of the timeshift. It's perfectly safe since if, for a moment, we forget that the TS file is "circular", everything before "NOW" in the timeline cannot be changed. It's there and there stays for the whole lifetime of the stream. When the stream is over, we don't need it anymore. Also the timer for the next program is safe, because the only thing that could alter that timer is a new tuning event on that stream where we need to reset the timer with a different nextprogram.starttime. Zapping isn't a big deal, we're not tuning while zapping. Since i'm using the tvhandler.currentprogram and tvhandler.nexprogram this isn't affected by pausing the tsreader. I don't know if i explained that well, i'll post the code. When i thought of doing it "server side" i was thinking more of creating the entire TSContext logic on the server (per stream, like now on my solution) and return the relevant portion to the client every time we use the timeshift feature. Since the server, and only the server, can write the stream, it seemed logical to me that it should be the only one that should create and handle this sort of "timeline" and recycle old programs. Moreover, this would open up to sharing streams (and it's timeline) to all clients that connect to that stream. (EDIT: i'm more thinking about placeshifting than really sharing the stream) Instead of embed those properties in the TS file which seems too complex, what about storing the whole timeline data on the server memory and ask for it from the client based on the tsreader position? This would make them indipendent from the tswriter, right? [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 2
Plugin Development
Trakt.tv LiveTV scrobble Development help request.
Contact us
RSS
Top
Bottom