...it doesn't seem very elegant in terms of slave backends.

The http://www.knoppmythwiki.org/index.php? ... ckendHowTo is an excellent workaround, but it's basically a kludge.

Don't get me wrong, I'm not ripping on cesman's solution to this problem.

Does anyone happen to know if later versions of mythtv is going to be more distributed-friendly?

I've had several slave backends and have been very happy with how it was setup and works.

The only real issue I've had is with the XBMCMythTV python scripts - they needed to be modified if you used local storage on the slave.

I guess having some kind of "configuration free" setup might be easier - but I was pretty impressed with how well it works the way it is...

From what I was reading, it seemed like the sbe stores the video on the mbe. The sbe's drive is largely wasted if it's only being used for recording TV. If the mbe machine's drive dies, everything recorded is gone.

Am I mistaken?

I hope no one thinks I'm critizing mythtv. I'm not. I'm just wondering if this is something where it could be better.

If disk space on the frontend(s) is a concern, you could go with a diskless frontend, booting over the network. Personally, I use the Seagate 40Gb drives for my frontends, which allows me to use MythArchive from any of them (and they are very quiet). If losing media is a concern, you really should have some type of backup plan in place - Drives die all the time, no getting around that. (Been there, lost that with ~110Gb of my wife's MP3s )

IIRC there are plans to allow storage on all Myth systems (just not available yet AFAIK). Yep, here's the ticket I was thinking of: http://svn.mythtv.org/trac/changeset/12151

This isn't just a front end machine. It's a backend too.

Thanks for the link. That changeset seems like a fix for one of the basic drawbacks to slave backends.

But doesn't it still seem like a kludge?

The problem that SBEs *seems* to have been designed to fix is to allow for additional remote tuners as a fix for the limitation of 4 tuners per machine.

I'm wondering if it wouldn't make more sense to get rid of the slave concept and just allow for multiple mysql databases, and each backend simply post recording requests in it's database when it has conflicts. Distributed processing isn't really new, and this seems like a cleaner solution to me.

Plug in a new mythtv box to the network, and suddenly the entire system has more resources. Unplug any one of them and the system just shrinks.

I'm not trying to offend anyone though.

It doesn't have to. Mine stores on its local drive, mainly because that was the easiest way for me to get it working with KnoppMyth installs.

I installed KM on a machine, edited the startup scripts so that it wouldn't init a local MySQL, and changed /etc/mythtv/mysql.txt to point to my main machine. Because everything else is using the defaults, it records into /myth/tv, which is local on this slave.

When I need to record more than my main machine can tune into, I just turn on the slave machine. The frontend magically discovers it when it boots, it records on its own disk, and the main machine gets the recorded files via the MythTV protocols.

Flexible (elegant) enough for me!

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

It does? So both machines are getting the recordings? Copies on both if the slave records them? But only copies on the master when the master records or are those on both?

I'm confused about what's happening when you say:


Also, what happens if you leave the slave machine on all the time?

Can either machine play recordings made from the other machine?

In case it sounds like I'm arguing, I'm not. I'm asking because it seems to conflict with the information I have, and I want to find out what's real.

The only limitation I am aware of for the number of physical tuners in 1 system is the number of PCI slots/USB ports.

I understand your point, but personally I wouldn't want to have to maintain multiple databases, especially when it comes time for an update!

The way I read Chris Pinkham's writeup on Storage Groups leads me to believe that to some extent this is where the project is heading. There would still need to be "uniqueness" for each system however, due to hardware differences, menu/media preferences, etc.

To steal from nigelpearson, right now the system is "Flexible (elegant) enough for me!" Looking forward to what the future may hold.

Hmm. Did something change? I thought there had been a limit of 4 per machine. Maybe I just had bad information.



I hear you, but using a script to update the mysql databases on 4 machines really isn't much worse than doing it on one. If the first one breaks from it, you still have the other machines to use while fixing the first, and then you know what can go wrong.

The really horrible thing about updates is when you have one giant system that you have insufficient space to backup and the update has to be done and working perfectly before Monday.

That sinking feeling you get when you know you can't take a step backward will always be with me.



It would seem like the change I suggest would require a big change at first, without a lot of immediate advantages. I had the impression that the only changes that really go in are the ones that add functionality or fix bugs. Making the concept change would basically be a step sideways at first, which is why I didn't think it was heading that way.



Sweet. I'm not complaining, or at least not intending to. MythTV is fantastic already and I definitely don't mean to belittle anyone's work.

It's difficult to really understand what MythTV can do though. Even the official mythtv docs don't list out the limits very well.

No copying. The backend on the slave machine "streams" the file to the frontend that you are watching from (it isn't the same machine). If the slave machine isn't on, the frontend puts up a dialog saying that the recording is unavailable.

Then all your machines will be able to view all the recordings, and the extra tuner(s) will always be available for recording from.

Try it out! If you have problems, I can help you work out what's happening with a few SQL dumps.

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

From what I've seen - the recordings can be stored anywhere you'd like them to be stored. I've stored all the recordings on the master in the past, but I now store recordings captured on the slave on the slave and recordings captured on the master on the master. You either store them locally or across an NFS mount.

There are not two copies of the recordings on the master - the database stores the computer name where the recordings were captured and finds them there.

The best way to see this in action is to see it in action. I really like the way the master/slave setup works - it does a good job distributing the load in my setup.

Master: 1 x PVR-150 with channel lineup #1, 800 GB storage
Slave: 2 x PVR 150, first with lineup #1, second with lineup #2, 400 GB storage

Then all your machines will be able to view all the recordings, and the extra tuner(s) will always be available for recording from.

Try it out! If you have problems, I can help you work out what's happening with a few SQL dumps.[/quote]

Ok, I will. If it works the way you describe, it doesn't have the drawbacks I was concerned about. It's worth the trouble to configure.

I already configured the second box as a MBE just like the first box. Will I need to wipe and reinstall the second box, or can I just point the mysql txt file to the first box? I'm not sure how much of
http://www.knoppmythwiki.org/index.php? ... ckendHowTo
I will need to do, but I'm guessing all of it.

The /mnt/mythtvslave and /mnt/mythtvmaster led me to believe that storage of tv worked differently.

Not at all. As long as they are both compatible versions, you should be able to use it as-is.


It does involve a few more steps. If you just change mysql.txt, your current backend will probably refuse connection (its mysql install has skip-networking set). Plus, you need to shutdown the backend and mysql on your slave, then run mythtv-setup and add the tuner cards, and then start the backend again.

I will try to write a simplified Wiki page for this, but basically you need to do most of the steps on the current Wiki except for the /etc/fstab, /etc/exports and NFS install/setup stuff.

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

I'm not sure what to do in the my.cnf file. It says to do this:
nano /etc/mysql/my.cnf
comment out the line that says "skip-networking"
restart MySQL (/etc/init.d/mysql restart)

But the file says:

I did everything except the skip-networking part, which I'm guessing I need to add the slave ip to or something.

Right now the slave keeps looping in a mysql setup connection screen when I try to open mythtv-setup on the slave.

Edit:
Do I need to change the line where it has bind address?
Right now it says:
Bind-address = 127.0.0.1

Should I add another line for the slave ip or just comment out this line entirely?

Edit^2: I commented it out and that worked, at least partly. The tuners I added are marked unavailable though, so I'm rebooting.

One thing the wiki didn't mention and should: the slave version is a tad different and all cards on the slave should be deleted before setting the IP of the master to be other than local.

I had entered the master IP as well as the tuner cards in one go. When I restarted, the background was different and the tuner cards were missing. I re-added the tuner cards but I was getting a Card 0 error until I removed a bad record from the cardinput table.

The cardinputid was 3, but the cardid and everything else was 0. Records 1 and 2 were for the master, and 4 and 5 for the slave. 3 was just garbage.