Print

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

[mattkhan]

Q as per subject basically

context being that I added a Windows box to my home network purely to run MC last year & that setup is now pretty stable. However, since windows is a single user OS, I need a separate box to deal managing the library (editing tags/creating particles and so on). Can MC Linux fulfill that role?

[mwillems]

Q as per subject basically

context being that I added a Windows box to my home network purely to run MC last year & that setup is now pretty stable. However, since windows is a single user OS, I need a separate box to deal managing the library (editing tags/creating particles and so on). Can MC Linux fulfill that role?

It sort of depends on what your needs and timetable are.

MC for Linux can interface with windows library servers/clients and edit tags, but MC Linux has some limitations right now.  For audio it can do most things windows can do (but not all), and the video functionality is in it's very earliest stages (as in just supported at all as of last build).  MC for Linux can currently serve video (but not transcode), but cannot be served video from another instance of MC. 

Basic video playback will likely improve in the near future, but some other windows features (like TV and a theater view replacement) are not necessarily on the near term horizon.  All of these things could pose challenges to using MC for Linux as a server or client.

Right now I have all my actual media on a Linux fileserver, but my MC library server on a separate windows box.  I do all my library management from a client on another windows box. 

My ultimate goal is to move my library server onto the linux fileserver using MC Linux, but I probably will not be able to do that until the video and server capabilities are a little closer to parity with windows.  That's primarily because the library server is the source of the view schemes for all clients (to include theater view schemes, etc.) and I need my server to handle TV recording.

Can you elaborate on your use case a little?

[mattkhan]

Can you elaborate on your use case a little?

I have a linux workstation upstairs which is used for general adhoc day to day use & a debian/xen server in my rack which runs an unraid vm and a debian vm for LMS (I have a few squeezebox players in different locations). I have 1 and only 1 windows machine in the house atm (the HTPC serving the cinema room) along with the usual assortment of mobile devices (all android) & a few laptops.

Therefore ultimately my use cases are

- use a jrmc linux client for pure library management (particle-ising TV series is a fairly labour intensive task) & this will probably turned into a source for headphones in my home office (which is fancy way of saying I have a desk in a bedroom)
- add a jrmc linux client in a vm on the main server to replace LMS (though would need to retain LMS as it seems to have much better support for UK radio/iplayer)
- add a jrmc linux client in a vm on the main server to share the load of serving video to tablets etc
- convert the HTPC to a pure appliance type device (i.e. no one will ever see windows, it just sits in theater view forever)

The only pressing issue I have is finding a device that is not the HTPC to do library management. Now that it is pretty stable/useable, I need to just leave the thing alone so that my family stop wondering what is going on with the black box that serves music/video to them!

[mwillems]

I have a linux workstation upstairs which is used for general adhoc day to day use & a debian/xen server in my rack which runs an unraid vm and a debian vm for LMS (I have a few squeezebox players in different locations). I have 1 and only 1 windows machine in the house atm (the HTPC serving the cinema room) along with the usual assortment of mobile devices (all android) & a few laptops.

Therefore ultimately my use cases are

- use a jrmc linux client for pure library management (particle-ising TV series is a fairly labour intensive task) & this will probably turned into a source for headphones in my home office (which is fancy way of saying I have a desk in a bedroom)
- add a jrmc linux client in a vm on the main server to replace LMS (though would need to retain LMS as it seems to have much better support for UK radio/iplayer)
- add a jrmc linux client in a vm on the main server to share the load of serving video to tablets etc
- convert the HTPC to a pure appliance type device (i.e. no one will ever see windows, it just sits in theater view forever)

The only pressing issue I have is finding a device that is not the HTPC to do library management. Now that it is pretty stable/useable, I need to just leave the thing alone so that my family stop wondering what is going on with the black box that serves music/video to them!

Got it.  MC Linux does currently support particle creation, but the video support is new enough that I might be tempted to wait a bit on your first use case.  The second use case may be workable in the near future depending on your needs.  The third and fourth are not yet doable (no transcoding yet and no theater view).

Something you should consider is that some library maintenance functions are not possible or easy to do from an MC instance in client-mode (even in the windows version).  For example operations involving cover art don't work from clients; rename, move, and copy operations don't work from clients; format conversion doesn't work from clients; ripping doesn't work from clients; some kinds of view editing don't always work from clients.  In order to do those tasks, you need to do them directly on the library server, or on a local library on the client PC.  

So there are two workarounds: remoting into your library server and doing the work there directly, or creating a local library on the workstation machine and point it at the same files as the remote library.  I do both sometimes, but I find the second one to be easier for anything labor intensive, and if you need a concrete example of the second case, I can layout my workflow.

[mattkhan]

I thought of one other use case that would be really nice, from a server utilisation perspective at least, is if jriver acted as a cluster when it came to serving clients (for sharing transcoding load etc). I have no idea whether the internal architecture of jriver is amenable to this but it would be great if it did it

Got it.  MC Linux does currently support particle creation, but the video support is new enough that I might be tempted to wait a bit on your first use case.  The second use case may be workable in the near future depending on your needs.  The third and fourth are not yet doable (no transcoding yet and no theater view).

Something you should consider is that some library maintenance functions are not possible or easy to do from an MC instance in client-mode (even in the windows version).  For example operations involving cover art don't work from clients; rename, move, and copy operations don't work from clients; format conversion doesn't work from clients; ripping doesn't work from clients; some kinds of view editing don't always work from clients.  In order to do those tasks, you need to do them directly on the library server, or on a local library on the client PC.  

So there are two workarounds: remoting into your library server and doing the work there directly, or creating a local library on the workstation machine and point it at the same files as the remote library.  I do both sometimes, but I find the second one to be easier for anything labor intensive, and if you need a concrete example of the second case, I can layout my workflow.

thanks for the info, I didn't realise that was the case for a client, quite annoying (well more annoying that windows is so resolutely single user but still). If you have time to layout your workflow then that would be much appreciated.

[mwillems]

I thought of one other use case that would be really nice, from a server utilisation perspective at least, is if jriver acted as a cluster when it came to serving clients (for sharing transcoding load etc). I have no idea whether the internal architecture of jriver is amenable to this but it would be great if it did it
thanks for the info, I didn't realise that was the case for a client, quite annoying (well more annoying that windows is so resolutely single user but still). If you have time to layout your workflow then that would be much appreciated.

Sure, here's how I import new media:

Machines:
1) Fileserver Machine: Linux with all media files on samba shares
2) MC Library Server Machine: Old Windows laptop sitting next to the Fileserver.  All the samba shares from the fileserver are mapped as network drives (W: Y: and Z:)
3) Client HTPC/Workstation: Windows Desktop in the living room.  All samba shares from the fileserver are mapped as network drives (same letters as Library Server)
(There are one or two other machines in play but they aren't relevant to the workflow).

When I want to rip CDs, import media, or do any other file-based library maintenance I use machine 3).  Machine 3) is normally a client on machine 2)'s library server, but when I'm processing media I switch the library on machine 3) to a local library.  Once I'm in the local library I rip or import media onto a local drive.  Then I rename, tag, get movie and TV info, etc.  Once all the files are appropriately tagged and processed, I use the rename, move and copy function to move the files and sidecars from a local drive on machine 3) to the shared drives on machine 1).  I have auto-import enabled on machine 2), watching the shared drives on machine 1).  So once the files land on the drives in machine 1), the library server on machine 2) picks up the files and the sidecars and imports them.  When I'm done importing/processing I switch machine 3)'s library back to being a client on machine 2)'s library server.  9 out of 10 times by the time I get the library switched back to client mode, the files have already imported and are waiting for me.  One tip: disable autoimport on the client PCs or strange results sometimes follow.

That method works for anything but a) MC updates on the library server and b) edits to view schemes.  For those I still need to remote into the server using a VNC or teamviewer.  I also use that method to do minor changes to cover art once the files are on the server.

In an ideal world, if MC linux had total feature parity, I could dispense with machine 2) entirely and just have machine 1) be the library server.  We're getting closer, but it might be a little bit yet for the reasons I noted above.