Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[evilhobo]

After having built a HTPC from parts and looking at a variety of software (eventually ending with MC), I've learnt that having the actual media on the HTPC is not the best of ideas. Many websites seem to suggest, and I agree with this view, that a single powerful backend serving multiple compact frontends is the best way to go about it.

For some time I've been searching for a software solution to this, including looking at MythTV and other Linux Media center software. Ultimately, however, I still cannot part with the comprehensive media library that can be built with MC. It has occured to me that MC would make a perfect backend system with a few modifications. Similarly, MC operating in client mode (using a network library) is sort of like a front end. However, in both cases, MC is still lacking.

For instance, as a front end, MC is unable to stream video, instead transfering the entirety of the file before playing it locally (this might be for audio too, but the delay is not as noticeable).
MC is also unable to serve live television. And only a single tuner is supported in any case (I know about zones, but its a very inconvinient way of having multiple tuners).

The perfect system, as I envisage is as follows:

BACKEND
A server with massive amounts of disks in RAID 5, a powerful CPU, decent amount of RAM, and basically a TV Tuner farm (maybe 4 or 6 tuners across 2 or 3 physical cards?). A full backend install of MC lives on this system and is responsible for the library. MC will be able to manage the tuner farm, such as distribute simultaneous recordings across the tuners as well as manage requests for live tv viewing from clients.

FRONTEND(s)
Compact system with low-end cpu, medium range gpu, and small disk (possibly just a flash card just for the OS and MC). The MC install on this system basically depends on the Backend to serve it with a library and with media (including tv).

So. Comments? is this /will this be possible with MC? Can I use something else to create this sort of system?

[ThoBar]

For instance, as a front end, MC is unable to stream video, instead transfering the entirety of the file before playing it locally (this might be for audio too, but the delay is not as noticeable).

If you connect to the library and media via a share, you can avoid this particular problem.

[Mastiff]

You can do just about anything with Girder and NetRemote.

[evilhobo]

If you connect to the library and media via a share, you can avoid this particular problem.

Still, not a true server/client system.

You can do just about anything with Girder and NetRemote.

Could you expand on that?

[Mastiff]

I retract that. I didn't read thoroughly enough and didn't see the S-word that I loathe (streaming). Maybe you should go for one of the hardware solutions? I think MC is able to stream video and audio to some of those. Sorry for wasting your time.

[fitbrit]

What you describe is similar to the SageTV system with the networked media extender. In one of the threads for features to be requested in MC13, I suggested a similar device that's compatible with MC rather than SageTV. That would be amazing. Currently my HTPC uses MC about 95% of the time. The media is stored on a 4.5 TB unRAID server which resides in a different room, connected by GigE. Streaming isn't a problem, as someone mentioned, using network shares. Still, it would be great if there were a device that was built from the ground up to run the MC Theater View interface.

[evilhobo]

Basically, MC as it is would make a great base for the 'ideal' server program I'm looking for, because of its comprehensive library/database system. Add to that better tv/recording support and media streaming that thats basically what I'd like.

For the client system, basically JUST the theatre view with some way of communicating with the server (basically cut down version of MC running in client mode) would serve as the client.

However, its not neccisary to have two different software packages or install setups for client/server eg currently jrmc can be both, so really, the only thing that needs to be modified is media streaming and tv support.


And for those that suggested media extenders, the reason why I use MC is for its library capabilities, such as its expression language and user defined fields and view schemes. AFAIK, media extenders cannot be expected to support that. Even if MC can stream to media extenders (and it seems to support upnp server), I won't have the nice tidy (sort of) view schemes that I've created. I guess for small media libraries, its not too much of a prob, but like many using MC, my library is MASSIVE.

[evilhobo]

What you describe is similar to the SageTV system with the networked media extender. In one of the threads for features to be requested in MC13, I suggested a similar device that's compatible with MC rather than SageTV. That would be amazing. Currently my HTPC uses MC about 95% of the time. The media is stored on a 4.5 TB unRAID server which resides in a different room, connected by GigE. Streaming isn't a problem, as someone mentioned, using network shares. Still, it would be great if there were a device that was built from the ground up to run the MC Theater View interface.

from what I understand, you have jrmc running on a htpc reading files of network shares. Thats sort of similar to what I have right now (reading both local and network atm). the problem is, I am looking to build a second htpc for another room. Whilst copying over jrmc files to get an identical library may work, I can't automatically sync those two now separate libraries. The cleanest solution IMO is to have jrmc on the file server feeding media to jrmc clients on the htpcs.



If someone is running a server and several htpcs can they tell me how to autosync a library? (basically, for some things, I'm very lazy)


In any case, the other half of the problem is tv tuner farming.

[ThoBar]

The trick is not to 'sync' the libraries, but to read them all from the same location.

For example...
 

• My server has an IP of 192.168.0.1
• The MC library is Shared as "y:\" ... (\\192.168.0.1\MCLibraries)
• The Media on the server is shared as "z:\" .. (\\192.168.0.1\Shares)
• My clients then map to these drives and read the library, and media, directly.

Using this setup, there are no synching process, no video file delay, no uncleared cache problem....

The tricks with this system:
 

• The server needs to see the media as being on "z:\" also, so that the relative path is the same for all machines.

 

• ^^ This can be accomplished a number of ways. Personally, I map the drives as this gives me easy control over the server's access to the files (no accidental media deletion from fat fingers or manic mice), however 'subst' or similar can do the job also. [edit] You may also want to look at NTFS junctions to get media from multiple drives into one share
• Library changes are not automatically seen by the clients, however a simple batch command that restarts MC (add into Theater View) will effectively do this on demand
• Network disconnections can be an issue, but a simple batch/vbscript file that is scheduled to run every minute can solve this - alternatively, you could use the UNC names for the shares which should alleviate most issues here
• The server should have MC running on it before any connections to the library are made by clients, this will lock the library to the server, and force the clients to see the library as read-only (if they have write access to the share). The alternative to this, is to use /readonly on the MC command line to force the clients. Personally, I use both methods.

Until MC has full Client/Server functionality (and it has been regularly requested, so JR is aware of it) I will use this or something very similar. UPnP is getting some love at the moment by the sounds of things (Or will when John G. gets back from leave -- I dont recall approving that request incidently  ), and so I am holding out some hope in that regard. I have used TVedia as a UPnP client with MC and video was well supported (dont try it with large libraries though, the client isnt as nice a MC's Theater View for that)


Cheers,
C.

[Marquis]

In general I am using the same solution as confishy, but with minor differences.

• I'm not using mapped network drives, but unc-paths directly. So no problem with not mapped network drives. A Girder script is checking for availability of the network before mc12 is started (by Girder also), but this is optional
• I run no mc12 instance on the server, because I don't want to use autologon for security reasons
• So the 1st machine loading the library is locking it instead of the server
• Also I found it's a good idea to disable auto-import feature on all HTPC. The service on the library, e.g. import new music, cover-art, auto-import, etc., is done from my notebook and not from any server or HTPC.

However, the BIG disadvantage is, that only the instance with write-access to the library can modify it. For example if I run two HTPC and #1 has write-access while #2 has read-only access the playcount, the rating, the genre, etc. changed on #2 are not updated. So I am also voting for at least for a database that can have write-access from multiple pc's.

cheers,
  Marc

[raym]

I run no mc12 instance on the server, because I don't want to use autologon for security reasons

Not an expert on this but I believe there are some 3rd party apps in existence which let you run MC as a service.

[Marquis]

I tried two solutions (one freeware, one commercial), but both version did not perform stable. If there is a stable solution, I appreciate a hint 

best regards,
  Marc

[kevind]

Good thread. This is a request I've been making for the last year. My company installs AV and automation systems with Media Center as the brains for music and music video  distribution. Media Center is always installed on a primary automation server (usually in a rack) reading music from mapped network NAS. This provides the main feed for the entire home and is controlled via touchscreens using Cinemar's software. We are not using MC on any "extenders" soley due to client/server design limitations of MC

One of the main  issues we have faced as are how to allow a user to manage their librarys and playlists from a remote location such as an office or kitchen PC so they don't have to go down to the server room and do all their work from there. The remote PCs have no job in playback.

Here is what we have done to overcome this but it is far from ideal.

On the primary server in the rack we run a bat file to ensure the mapped drives are in place.
On the primary server MC is set to monitor for changes/auto import, auto anaylize, import covert art, auto import settings "Ignore Files Previously Removed" is unchecked and "Fix Broken Links = yes" (Not Protect network files). I'll talk about the latter in a moment.

On the remote PC MC is installed and set to monitor the same mapped drive. All ripping and management of the library is done from this location. What we have found, and someone please comment if I'm doing something wrong here, is that one of the primary keys to this is the "Fix broken links" setting. If you have the primary MC server set to "protect network files" any changes or file deletions done from the remote location DO NOT take effect. This of course is a real problem as the user makes a tonne of changes: genres, delete songs they don't want anymore etc but the primary MC will ignore them and ultimately you end up with a tonne of "No  file to play" warnings happening on the primary MC. Changing to "Fix Broken Links = Yes" allows the primary MC to update itself

The problem of course with this is if the network goes down then the primary MC library is not protected...hence the setting of unchecking "Ignore Files Previously Removed" so that once the network is reconnected, auto import will find the files and rebuild the library since the files still exist. If the files are actually permanently deleted then there is nothing to find and it updates itself accordingly.

Very clumsy but I have not found any other solution. This is a major issue in a world of distributed home audio system. I so wish MC would have a "remote client" function for controlling a master MC. This would be ideal for on screen theater view music control from any location in the house....select music onscreen and it tells the master MC to start playing....not the local one.

Remote playlist management on the other hand is another problem. So far the only solution we've come up with is to show the user how to "export" a playlist created on a remote PC to a master playlist folder located on the NAS....very clumsy. The master playlist folder is set to be monitored by the master MC program for any changes. For this we'd love to see a setting inside MC that allows you to store playlists in a specific location automatically if desired vs locally only.

That was a mouthful...

[raym]

Remote playlist management on the other hand is another problem. So far the only solution we've come up with is to show the user how to "export" a playlist created on a remote PC to a master playlist folder located on the NAS....very clumsy. 

A "silent" switch was recently added to the export all playlists core command which is great. This allows me to export playlists on the client via a recurring scheduled task without the need for any user interaction. So on each client, the task does the silent export ("MC12.exe /MCC 20004,1") and then copies these playlists to the server where auto import picks them up from there.

Yet another hack for a common request but this solution has allowed me to get closer to a remote playlist management solution than ever before.

Cheers.

[evilhobo]

Thanks for the replies all, esp confishy and Marquis.
It'll mostly achieve what i want (except tv tuner farming/streaming)

I was wondering if the following variation would work instead:

on the server, i create a share for each drive called d-drive, e-drive etc.
on the server, jrmc creates a library that searches from //server/d-drive, //server/e-drive etc rather than D:\, E:\ etc

the clients will then be able to read from this library and (in theory) path names would not be an issue as everyone is using UNC.

will this work?

the reason is I don't like mapping network drives. bad experience with constant disconnects put me off them a few years back.
the idea of junctions is also interesting. i've been reading into vista symbolic links but apparently they don't work over network shares. so i might just try ntfs junctions.

btw, does jrmc work on server os's? (windows server 2003/possibly 2008)

[swinster]

On the primary server in the rack we run a bat file to ensure the mapped drives are in place.
On the primary server MC is set to monitor for changes/auto import, auto anaylize, import covert art, auto import settings "Ignore Files Previously Removed" is unchecked and "Fix Broken Links = yes" (Not Protect network files). I'll talk about the latter in a moment.

On the remote PC MC is installed and set to monitor the same mapped drive.

Are you saying that you have two separate instances of MC running on different computers, each with maintaining thier own libraries rather than using the one master library?

I have just started looking into these issue. I have recently been using the FREE Media Jukebox on a single PC that uses files stored on a network share. I must say that library updates a VERY SLOW. In addition, I have just tried to synch the iPod and this has and estimated 5 hours left to run, after running for about 4 hours already - approx 35 GB  of music, 0.4 MB/s transfer rate, admittedly this is over WiFi, but a good connection nevertheless. Will things improve if I use MC as a server with the Jukeboxes as clients?

I am looking to expand the number of PC connecting to the share but wanted a more client server base so was looking to install MC on the server (SBS 2003). However, it appears that this functionality is still a little haphazard in Media Centre. Are there any improvements in MC13?

Chris

[JimH]

The sync rate is probably slow because it's connecting at USB 1 speed, not USB 2.  You could try another port.  A google search might also help.

[swinster]

The sync rate is probably slow because it's connecting at USB 1 speed, not USB 2.  You could try another port.  A google search might also help.

I managed to synch a LOT faster when the library was on the local machine - a 2 year old laptop so not sure if it will have any USB 1.1 ports.

[JimH]

Please try a google search on that.

What build are you using?

[swinster]

I'll try and keep this short as the iPod sync thing seem a little off the main topic.

Have spent the last hour or so searching the forum with no real answer. Originally, the iPod sync'ed at around 5-6 Mb/s using local storage. From a standard Windows point of view, in device manager, the Apple USB device is detected on the "High Speed" hub. Tried reseting the hub and using a different port, but still the sync speed is down at 0.5-0.9 Mb/s.

The build of JukeBox is 12.0.47 - the latest I think. OS is Vista SP1

-------------
More on main topic - are there any updates in MC13 that enhance any client server functionality?

[cncb]

And for those that suggested media extenders, the reason why I use MC is for its library capabilities, such as its expression language and user defined fields and view schemes. AFAIK, media extenders cannot be expected to support that. Even if MC can stream to media extenders (and it seems to support upnp server), I won't have the nice tidy (sort of) view schemes that I've created. I guess for small media libraries, its not too much of a prob, but like many using MC, my library is MASSIVE.

For what it's worth I wrote an add-on for SageTV that reads the MC library and allows you to browse your view schemes, play playlists, smartlists, etc. within the SageTV interface.  It uses SageTV as the player which means you can use it on their extenders.  It works well for me - I use the MC library to manage everything but TV recordings.  Click the link in my signature for more information.

[AustinBike]

I have a pretty good system.

I have a main workstation where I do all of my tagging and library management.  All of the data is kept on a DLink NAS:



It has gigabit speed and can hold up to 2TB (supports 2 SATA drives).

The library is stored on the NAS and the music is also on the NAS.  I map every system in the house to M:\ for music and K:\library for the library. The main workstation does not need to stay on, it can be shut off.

The only downsides to this system is that the other clients cannot change the library, only the first one to log in can change it, all others would log in as "read only".

The NAS has a built in UPnP server and a built in ITunes server, so, theoretically, I could set up either of those for serving music as well.

[Tanoshimi]

Here's my two cents, and hopefully I can help someone else. 
- I have a library where all the media is stored on a shared NAS drive mapped on all computers as the V: drive.
- The library is also stored on this NAS drive and loaded by all machines.
- The main desktop used for working with the library loads them in full access mode.
- On the other two machines, all shortcuts and links have had the /LibraryReadOnly argument added.  This ensures that only the desktop can write the files, and everyone else gets read only access.

This approach has worked well for me, and is faster and simpler than any kind of server approach (which usually required full transfer of the file before playing).  As anyone who's done this knows, there are a few problems with this approach:
1. Playcounts are not updated when items are played on ReadOnly machines.
2. Updates to the library are not mirrored to the other units.

I believe I have a solution for both of these situations, and if anyone is interested, their input would be welcome.  My solution is to write a plugin (yes, I can do this) that will store a log on the shared network drive.  Whenever a file is played from one of the ReadOnly Machines, that item will be added to the log.  The Desktop running in full access mode will monitor this file.  When it changes, it will increment the NumberPlays field (if it's possible to do so, if not I'll create another field that can be incremented as a playcount).  The ReadOnly versions will increment their playcount as well.  Even though the changes won't be saved, this should keep them in line with the actual library until the next update.  This should effectively solve the Playcount issue. 

As for Updating the ReadOnly versions, a simple batch file containing the MC12 command to run it in read only mode should refresh the library.  This same plugin can monitor that log and when changes are made, or every N minutes, refresh the library.  You definitely don't want to do this often though.  If I'm listening to MP3's downstairs, and someone is watching a movie upstairs, you don't want it to refresh their library after each song.

One other thing.  A lot of talk has been done over having a smaller version of MC12, just a readonly Theater View based unit (with playcount support of course) for use on those machines that are only used as players.  I had previously written a very small program that used HTML to display a player (making it very easy to create skins).  Clicking the designated hyperlinks executed program commands (Play, Pause, Next, Exit, etc).  This interfaced with WMP.  Now it would not be too difficult to modify that program so it opened a connection with the shared library and presented a Theater View style interface for navigating menus/playlists/media, then played selected items in WMP. 

I know that's kinda against the point of MC, but until they come up with a smaller player, or allow us to add submenus or library commands to the Theater View menu, it's an option.  Not sure I'll take that one up though.

If anyone is interested in a plugin that will update the main library's playcounts from readonly instances of MC12, chime in.
-Tano

[Listener]

> A lot of talk has been done over having a smaller version of MC12, just a readonly Theater View based unit
> (with playcount support of course) for use on those machines that are only used as players.

If it didn't support standard view mode, it would be completely useless to me.

MC in Theater View lacks all the UI features I value in MC.

Bill