How to completely disable/de-install timeshift? (2 Viewers)

[DragonXG]

I see the light.

I now consider myself enlightened as to the mystery of TimeShifting... mostly.
I am :sorry: to burden you with my stupidity yet again, but...

Tv-Server is smart and does the following:
* Client1 watches ChanA -> Client2 wants to watch ChanA as well = TvServer will not tune the same channel on an other card, it will just use the card which is allready tuned to the same channel. so you can even go back and watch the entire TsBuffer created by Client1
* Client1 watches ChanA -> Client2 wants to watch ChanB which is on the same Transponder as ChanA = TvServer will not tune ChanB on an other card, since the data is allready received inside the currently tuned transponder
...
The Tv-Server automatically creates an RTSP stream for each tuned channel, to which multiseat clients connect to.

Does the TS save the transponder data [all contained channels] or just a watched channel?

With another analogy, a 4 tuner TVServer is in an area receiving 4 transponders with 5 channels each [20 channels total], and the Client base happens to have at least 20 simultaneous Users, each watching a different channel [maximum load].
How many TS file sets would be created, 4 or 20?
At a guess, it would be beneficial to have one tuner per transponder, that way everyone can watch/record anything, anytime. No conflicts?

 

[infinite.loop]

Does the TS save the transponder data [all contained channels] or just a watched channel?

Just the watched channel + all its audiotracks/subtitles/etc.
Dumping the whole Transportstream would generate an insane amount of data. HDD would be filled in no time.

With another analogy, a 4 tuner TVServer is in an area receiving 4 transponders with 5 channels each [20 channels total], and the Client base happens to have at least 20 simultaneous Users, each watching a different channel [maximum load].
How many TS file sets would be created, 4 or 20?

between 120 and 400 files.

For each tuned channel Tv-Server can generate between 6 to 20 TsBuffer files (configure able values - minimum is 3 files).
Now you might wonder why we do not have just one file.
As soon as you tune a channel, the first TsBuffer file is pre-created with 256MB Size. as soon as this is full, the 2nd one is created, as soon as this is full the 3rd one is created ..... as soon as the 6th one is full, the first one is "cleared" and re-used.
So you have a re-use cycle of the files. This is how you define the size of your timeshiftbuffer. Reason is that smaller files are faster to handle that big ones.
Now we could have made a setting like "TsBuffer = 2 hours". But this is not good, since you might only have enought space on your HDD for 2hours, lowbitrate SD Channels. And as soon as you watch an highbitrate channel, or HD-Channels -> problem.

So you have to take the amount of clients, and then caclucate the max TsBuffersize. Then you wont have any issues at all.

At a guess, it would be beneficial to have one tuner per transponder, that way everyone can watch/record anything, anytime. No conflicts?

If you have 4 Tuners + 4 clients, then all clients can watch whatever they wont. UNTIL some scheduled recording(s) are going on, which have priority.

But inside MyTv -> Channels, MediaPortal always displays you which channels can be tuned (same transponder) and which can not.
So to follow your example.
5 Channels on the same Transponder -> 4 clients -> 1 Tv-Card -> all 4 clients can watch these 5 channels on the same transponder.
MP will display you only these 5 channels as tuneable.

So to be on the absolute safe side you sould have as many cards as you have clients + one for scheduled recordings in your Tv-Server PC.

 

[DragonXG]

Almost there...

So to be on the absolute safe side you sould have as many cards as you have clients + one for scheduled recordings in your Tv-Server PC.

Until you need to record 3 different channels at the same time [this seems to happen frequently here when TV rating time comes around] and perhaps watch a fourth. Only one client, but 4 tuners required.
If a Client could watch a channel that is being recorded, as opposed to watching the recorded file [the file could not continue after the recording has finished] it would be possible to have 3 tuners.

How about this...
At 6.00, after a nice dinner, Client 1 [parents] set a schedule to record an 7.30-8.30 Program on Transponder A:Channel 1 and proceeds to watch Transponder B:Channel 2.
At 6.15, after the dinner cleanup, Client 2 [kids] set a schedule to record a 6.30-7.30 Program on Transponder C:Channel 3 and proceeds to watch Transponder D:Channel 1.
Assuming both Clients are still watching TV when the recordings start, this analogy would need to use 4 tuners due to the pre/post recording overlap, yes?
With 3 tuners, who would lose their TV?
With 2 tuners, who loses their TV first?

 

[infinite.loop]

If a Client could watch a channel that is being recorded,

That he can.
+ he can watch all channels on the same transponder as i allready explained.


If all cards are busy, and TvServer has to start a scheduled recording, then the following happens:

1. TvServer looks which card is able to tune the required channel
2. TvServer looks which card is free
3. if none is free it looks if one card is tuned to the required transponder
4. if no card is free nor tuned to the required trransponder, then it will take the tv card with the higest priority (config value) and make it free -> kick the client (that also is a config option, you can turn the "kick user for scheduled recordings" on/off)

 

[tourettes]

If all cards are busy, and TvServer has to start a scheduled recording, then the following happens:

1. TvServer looks which card is free
2. if none is free it looks if one card is tuned to the required transponder

1. 
   
   I think we would need to have a option to change that card allocation algorithm a little bit. Currently it is possible to have two muxes and two cards and still get unable to tune a channel in some situations (happens approx once per week on my HTPC).
   
   - user watches channel A from MUX A´--> first tuner is used
   - recording is scheduled from channel B (or even A) on MUX A --> second tuner gets used (even when it shouldn't !)
   - user tries to watch channel C from MUX B -> fail
   
   It is just not optimal for all use cases to find the free card first. Would be much better if allocation algorithm would pick up the used cards first if those are valid.
   
   Either it is that, or some bug that causes tuners to get locked. I would assume that it is a bug and the card allocation is using the already tuned cards (when using sub channels) first.

 

[Owlsroost]

Would be much better if allocation algorithm would pick up the used cards first if those are valid.

I think that is what happens on my 1.0.2 installation (with 3 x USB DVB-T tuners).

What I have noticed is that if a tuner is being used for EPG grabbing it seems to become the 'first choice' tuner when a recording starts, even if another higher priority tuner is free.

Tony

 

[infinite.loop]

imo. a scheuled recording always has to be prefer a free card, and not one allready tuned to an other channel on the same mux.
reason is that if the user wants to change channels, the server has to "change cards", and that first tune on an other card will cause an extra delay on zapping.

as far as i remember, on my server pc, a scheduled recording always picks the first free card.

 

[tourettes]

imo. a scheuled recording always has to be prefer a free card, and not one allready tuned to an other channel on the same mux.
reason is that if the user wants to change channels, the server has to "change cards", and that first tune on an other card will cause an extra delay on zapping.

as far as i remember, on my server pc, a scheduled recording always picks the first free card.

No, it won't be always the optimal solution to use the free card. Just think my example. having two tuners should be always enough to receive and record all programs from two muxes but now it isn't and I'm facing that issue on weekly basis (thats why I proposed the option, as some would prefer to have the allocation done differently).

Is it better to have slow zapping (one change only when zapping away) or not possible to use the 2nd mux at all?

 

[infinite.loop]

imo. a scheuled recording always has to be prefer a free card, and not one allready tuned to an other channel on the same mux.
reason is that if the user wants to change channels, the server has to "change cards", and that first tune on an other card will cause an extra delay on zapping.

as far as i remember, on my server pc, a scheduled recording always picks the first free card.

No, it won't be always the optimal solution to use the free card. Just think my example. having two tuners should be always enough to receive and record all programs from two muxes but now it isn't and I'm facing that issue on weekly basis (thats why I proposed the option, as some would prefer to have the allocation done differently).

Is it better to have slow zapping (one change only when zapping away) or not possible to use the 2nd mux at all?

But if the scheduled recording starts on a card which is allready in use by an other user, then this user is the owner, and if the owner changes the channel...... wouldn't that kick the recording?

 

[tourettes]

imo. a scheuled recording always has to be prefer a free card, and not one allready tuned to an other channel on the same mux.
reason is that if the user wants to change channels, the server has to "change cards", and that first tune on an other card will cause an extra delay on zapping.

as far as i remember, on my server pc, a scheduled recording always picks the first free card.

No, it won't be always the optimal solution to use the free card. Just think my example. having two tuners should be always enough to receive and record all programs from two muxes but now it isn't and I'm facing that issue on weekly basis (thats why I proposed the option, as some would prefer to have the allocation done differently).

Is it better to have slow zapping (one change only when zapping away) or not possible to use the 2nd mux at all?

But if the scheduled recording starts on a card which is allready in use by an other user, then this user is the owner, and if the owner changes the channel...... wouldn't that kick the recording?

With two MUXes such wouldn't happen as there is always enough cards to handle the situations (but current algorithm doesn't cope with that). So, it is not optimal for all use cases and I'm personally hit with that limitation

And for general use cases it could be always done is such way that the ownership if the tuner is always transferred to the recording. In this case the only side effect compared to the current behavior would be the one tune event (one extra card swap on the first off-MUX tune) that takes more time, And as a positive effect it would allow less tuners to be used when recording wouldn't lock up any tuners when they aren't explicitly needed (sharing is caring ).