Multiple tuner support = multiple copies ?

[Paul McHale]

If I use multiple tuners, do I have to run multiple copies of sagetv? Are multiple tuners transparent to the user ?

[carlgar]

A single copy of SageTV will support multiple tuners. Not quite sure what you mean by transparent but believe the answer is yes for the most part. However, the tuner assignment logic may not be exactly what you expect. For example, I have a favorite show with both leading and trailing padding of 2 minutes. If the favorite is shown back to back on the same channel, I expected first show on tuner1 and the next on tuner2 with a 2 minute overlap. What I currently see is the shows recorded using only 1 turner, which can result in a loss of a few seconds of data, if the programs do not start and end at the exaxt time.

[fidget]

Originally posted by Paul McHale
If I use multiple tuners, do I have to run multiple copies of sagetv? Are multiple tuners transparent to the user ?

If all of the tuners are in the same computer then you will only need one copy. I have one computer with two tuners, but a second computer with a third. In this second computer, I have Sage Recorder installed so that my copy of SageTV can access that tuner over the network. Aside from the initial setup of that third tuner (network encoders take a special configuration), SageTV thinks it just has three tuners to use.

[wr202]

fidget, what happens if your first computer locks up or is down temporarily? Would the second computer being able to record what had been scheduled? Do both computers need to be up all the time for the network to work properly?

[fidget]

Originally posted by wr202
fidget, what happens if your first computer locks up or is down temporarily? Would the second computer being able to record what had been scheduled? Do both computers need to be up all the time for the network to work properly?

There is currently no ability for two SageTV servers to work on a peer-to-peer basis. I don't know if that is a feature for SageTV 2.0, but it would be nice. SageTV does handle the network encoder being brought offline quite well. When it comes back online, it gets automatically added to the list of encoders.

The problems that I have read (but my system does not duplicate) with network resources has to do with storing all the files on a remote computer. If that computer is reset then SageTV will "forget" about the files stored there. This is not a problem with my system since all the files are stored locally.

I run XP home on my machine, with a UPS connected for power, and haven't had a problem with the computer hanging or crashing. It does have a bazar time problem if it has been on for more than two weeks (it gets to be 2 minutes fast), but other than that it has been very reliable. A quick reboot solves my clock problem.

[Paul McHale]

To cure your clock problems, consider an NTP client. One I would suggest is:

http://www.thinkman.com/dimension4/

It is free and will automatically set yo clock. I use day.speakeasy.net as my time server. There are about a dozen suggestions in the program. It works very well and should solve your problem.

Maybe version 2.0 could include internet clock setting via ntp? I don't think it is that hard unless extreme accuracy is desired. Dimension 4 is usually sub .5 seconds of error. Mostly fractions of a second. Even a poorly written one should be within a few seconds. The last time it synchronized it was .02 seconds off.

[ErsatzTom]

Originally posted by fidget
There is currently no ability for two SageTV servers to work on a peer-to-peer basis. I don't know if that is a feature for SageTV 2.0, but it would be nice.

I would think that this would be pretty hard to implement. All of the data would have to be replicated on each system and kept synchronized. I suppose you could do this with an relational database (which I would love) that supports replication. Otherwise, if the guide data, favorites, etc goes off-line how would another tuner know what to record? Also, all running instances of Sage would have to negotiate who was going to be making the scheduling decisions. Also, Sage Client would have to be able to either discover servers or have multiple address to try in case its primary goes down (probably both solutions to make normal lan configurations easy while making it possible to have less common internet/segmented network setups work).

And think about this.. if you have all you machines up but there is a network outage. Now all your servers think that they are the only server still up. They would all start recording the same shows. Also, since an outage would almost certainly happen in the middle of recordings, how would that situation be handled?

I agree it would be very cool if they could make this work but it probably adds more problems than solutions.

t

[fidget]

Originally posted by Paul McHale
To cure your clock problems, consider an NTP client. One I would suggest is:

http://www.thinkman.com/dimension4/

It is free and will automatically set yo clock. I use day.speakeasy.net as my time server. There are about a dozen suggestions in the program. It works very well and should solve your problem.

Maybe version 2.0 could include internet clock setting via ntp? I don't think it is that hard unless extreme accuracy is desired. Dimension 4 is usually sub .5 seconds of error. Mostly fractions of a second. Even a poorly written one should be within a few seconds. The last time it synchronized it was .02 seconds off.

My problem is strictly an XP problem. If I reset the clock, it will slowly get faster until it reaches 2 minutes (usually within 2 hours) and then stay stable. The only way I can get things to reset properly is to resynch the clock with a time server and then reboot. I really don't want to have to resynch the clock every half hour, which is the only alternative .

What is really odd is that the clock does not run slightly fast (i.e., does not gain 10 seconds per day). It says rock solid until some point then jumps to running 2 minutes fast.

[fidget]

Originally posted by ErsatzTom
I would think that this would be pretty hard to implement. All of the data would have to be replicated on each system and kept synchronized. I suppose you could do this with an relational database (which I would love) that supports replication. Otherwise, if the guide data, favorites, etc goes off-line how would another tuner know what to record? Also, all running instances of Sage would have to negotiate who was going to be making the scheduling decisions. Also, Sage Client would have to be able to either discover servers or have multiple address to try in case its primary goes down (probably both solutions to make normal lan configurations easy while making it possible to have less common internet/segmented network setups work).

And think about this.. if you have all you machines up but there is a network outage. Now all your servers think that they are the only server still up. They would all start recording the same shows. Also, since an outage would almost certainly happen in the middle of recordings, how would that situation be handled?

I agree it would be very cool if they could make this work but it probably adds more problems than solutions.

t

There is already a way to tell the server about the location of remote encoders, so I would like to make each remote recorder be a potential server. If it is an instance of SageRecorder, then it would not be given the chance to be the master server.

What I would like to see is each recorder storing its program list. I would also add the list of recorded programs to the protocol that is used to communicate with remote encoders. This way, if I have a copy of SageRecorder on a networked machine (or a peer SageTV instance), it would know which shows it has recorded. When I want to play a show back, my client communicates with the recorder instance and it is played back through there. If the recorder (or peer SageTV instance) is reset then the list of its programs would be transferred once it came back online and was detected by the other serers.

I do network programming for a living and the discovery of other servers is very simple, especially when you know where they are suppose to be. SageTV already does this with networked encoders. If it used something like Rendezvous then I wouldn't have to give it a list of servers (pardon the cool technology plug, I got carried away). Mastership could be assigned to the server with the highest IP address.

In my home, if the network is down then I have lost power to my house (my PCs are on UPSs but the switch is not). In this case, I don't care if I get duplicate programs recorded. If I can prioritize my favorites then I can make sure that nothing important will be lost. If I can get my butt in gear an put the router and video amplifier in a switch as well then I won't lose the network. If I lost power in the middle of a recording, I would expect the recording to finish. You may not get the top-priority program, but you will get the entire program you were recording.

[ErsatzTom]

Well, I write this kind of code for a living too and I'm familiar with Zeroconf (and not just because I use a Mac for my main workstation). While these kinds of standards certainly help make some elements of the solution less complicated there are still some pretty big hurdles to clear. This problem set is similar to bi-directional database replication services which are notoriously difficult to implement. For example, two servers can't communicate for some reason and both assume the primary schedule/client interface role it would be possible for both to have a different set of scheduling changes made either directly or through a client before they had to resynchronize. When they reconnect, those changes would have to be merged. This sort of situation might be uncommon, but a solution either has to solve them or find a way to avoid them (prevent scheduling changes to servers which have temporarily assumed master status or something).

Rather than try to make a true distributed server environment, maybe a much more limit set of functionality would solve many of the problems. A single sage server could still be responsible for all scheduling and client communication but perhaps giving network encoders scheduling information further in advance. Perhaps even alternate scheduling information in case they loose contact with the server or other network encoders to make sure that high priority recordings aren’t missed.

t

[fidget]

Originally posted by ErsatzTom
This problem set is similar to bi-directional database replication services which are notoriously difficult to implement.

To me, this is similar to the "database" issues that I get hit by in an avionics system. I put database in quotes because it isn't as complicated as a real database (its more of a data store, but we call it the database).

On a non-commercial aircraft (the rules change drastically for FAA certified software), we tend to have a master/slave relationship between the peer functions. The master process performs all functions and then transmits the "database" out to its peers at a given rate (in my case, transmitting an 80KB flightplan once every two seconds). The theory being that if the master fails, the data being retained by the slaves won't be too old for them to successfully take over control.

In the case of SageTV, the master could send out the list of programs to record, their prioritization and their tuner selection to each of the slaves. If the master crashes, or the network, then the slaves should have enough information to continue working. Each potential master should have a copy of the recording schedule and the next master (by some arbitrary decision) can then take control. Those tuners currently recording would continue until the end of the program and those not recording would take commands from the new master (which would be very similar to what the old master would give). When the user went to the Sage Recordings screen, the master would ask each recorder for its list of programs and build the proper composite list. If, somehow, I brought a clean system up as the master then the older, more knowledgeable servers, should be able to update their information into the new machine.

This would only work because the amount of data that SageTV needs to transfer is minimal. If the data were extensive enough as to require a SQL server then I could see some major problems.