Print

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

[cncb]

- Is the media server process that runs in the UI context the server component?  If so, why does it run in the UI context instead of as a service?  Running as a service would make it more robust and able to restart automatically if a crash occurs.

I requested this a long time ago (and several times since then).  Having playback or something else in the main UI crash the TV recording engine and thereby messing up a recording in progress is uncool and unacceptable.  Unfortunately, it seems unlikely it will be changed.

[gvanbrunt]

There is nothing special about a service, it is just a standard program. You are correct that it can be forced to restart if it crashes. (not if it hangs though).

You can get a similar effect using some of the tools here:

http://www.google.ca/search?q=monitor+a+program+and+restart+if+crashes&rls=com.microsoft:en-us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1&redir_esc=&ei=8vmdTtWYOdH8qAH70M3JDg

You can also make an application run as a service (see google), but it is not a reliable as a watchdog. It may be possible to monitor MC via an API to see if it is hung or not using a watchdog. That you can't do as a service.

[babgvant]

There is nothing special about a service, it is just a standard program. You are correct that it can be forced to restart if it crashes. (not if it hangs though).

That's not true.  Services and UI session processes follow different rules; this is even more true on Windows Vista and later OSes.  Most importantly, a service has baked in support for reliability, remote management and notifications.  There is simply no substitute for those wishing to run a headless server installation, or if you have concerns around the UI session ending (i.e. an accidental logout).

You can get a similar effect using some of the tools here:

http://www.google.ca/search?q=monitor+a+program+and+restart+if+crashes&rls=com.microsoft:en-us&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1&redir_esc=&ei=8vmdTtWYOdH8qAH70M3JDg

You can also make an application run as a service (see google), but it is not a reliable as a watchdog. It may be possible to monitor MC via an API to see if it is hung or not using a watchdog. That you can't do as a service.

I agree that there are ways to run normal applications as a service (I've written shim services for this purpose in the past), and create wrappers around UI session processes to emulate the same sort of services that the OS provides.  The point is more around good design and leveraging existing, tried, and supported methods for managing actions that should be run from a service.  These other approaches are hacks that only come close to what is available w/o effort from the OS.

I find it shocking that knowing the workload handled by this process that anyone would argue that it shouldn't be encapsulated in a service process on a modern OS (read Windows XP+).  There may be legitimate historical reasons why it was implemented in this way, but let's be honest about what the right way to do things is and not pretend otherwise.

[gvanbrunt]

We could argue all day about the differences between services and regular processes, but at the end of the day a service is still a program and is prone to all the same problems as a regular process. A poorly designed service will not be better than a process that is designed well.

I was not attempting to debate the merits of MC's design either. My suggestions were an attempt to help you get what you want until JRiver decides to implement your suggestion. However, for every person that wants it to be a service there are more that would complain that it is hogging resources when they are not using it. On a dedicated HTPC or media server a service makes sense. On a regular computer it does not (for most people). I believe a majority of the instances of MC are the later and that is probably JRiver's reasoning. If they were to break it into two parts it would also be harder to use for the average user.

As a programmer I understand there are pros and cons to every design. What is bad for one user may be perfect for another. Making blanket statements about "the right way to do things" simply isn't true. Knowing the care and a detail that JRiver puts into their product from the ground up to create an audio engine that is second to none, and the constant refactoring and refining you read in the release notes also makes it hard to me to believe they don't know what constitutes good design. You may not agree with their decisions, but that does not make it wrong.

Personally I would like to see it broken into a front and back end, but I understand why they are reluctant to do so. I struggle with the same issues you do as I have a dedicated htpc/server and when MC crashes it causes some grief. Thankfully it does not do it all that often...

[babgvant]

We could argue all day about the differences between services and regular processes, but at the end of the day a service is still a program and is prone to all the same problems as a regular process. A poorly designed service will not be better than a process that is designed well.

There's no need to argue; the differences are documented so there's not much to discuss.

I didn't claim that wrapping bad code in a service would imbue magical powers upon it.  You are correct that at a fundamental level, a process is what it is, but the point is that if you have a server workload that doesn't need UI interaction running it as a service nets benefits that are difficult (i.e. not free) to replicate in the UI session.

I was not attempting to debate the merits of MC's design either. My suggestions were an attempt to help you get what you want until JRiver decides to implement your suggestion.

This is probably the disconnect; my goal wasn't to find a workaround.  I am approaching this as a potential user (currently using SageTV, which has a robust client/server 10" experience) and a connected home reviewer.  In both scenarios the current implementation is a significant con.

However, for every person that wants it to be a service there are more that would complain that it is hogging resources when they are not using it.  

The resource difference b/w running something in the system tray and as a service is negligible and it is an optional process, so those people wouldn't have much standing to complain.

On a dedicated HTPC or media server a service makes sense. On a regular computer it does not (for most people). I believe a majority of the instances of MC are the later and that is probably JRiver's reasoning. If they were to break it into two parts it would also be harder to use for the average user.

It's already two parts (actually three because a service component as well).  I don't see how putting something that should start by itself and run unattended creates a more complex system.  This thread was about the client/service experience after all.

As a programmer I understand there are pros and cons to every design. What is bad for one user may be perfect for another. Making blanket statements about "the right way to do things" simply isn't true.

Put ten application architects in a room then define the workload and use cases.  How many of them do you think would pick system tray for this application?  Frankly I'd be shocked if any of them did.  In this case I think it's OK to say there's a right way, and running a server workload from the UI session's system tray isn't it.

Knowing the care and a detail that JRiver puts into their product from the ground up to create an audio engine that is second to none, and the constant refactoring and refining you read in the release notes also makes it hard to me to believe they don't know what constitutes good design. You may not agree with their decisions, but that does not make it wrong.

There may be valid reasons for keeping the wrong design (e.g. limited developer resources, other priorities, lack of demand, etc.) that justify the decision, but it doesn't make it less wrong.  

[gvanbrunt]

There's no need to argue; the differences are documented so there's not much to discuss.

We both agree there are differences between services and regular processes. Your comments seemed to imply that having the process as a service would somehow fix this automagically. Your comment however seems to make this clear that this is not what you meant.

The resource difference b/w running something in the system tray and as a service is negligible and it is an optional process, so those people wouldn't have much standing to complain.

A service runs all the time. The system tray application does not so it is going to use more resources when not in use on most users computers who don't run it full time. It's going to result in longer start up times as well. Of course the service portion could be made optional, then it wouldn't matter. A service is great on my HTPC, but not what I want on my other 2 computers. The system tray process at least gives users a choice.

Perhaps there is not much work for JRiver make that part able to run as either a service or a tray app. A service could be created in a disabled state so a user could turn it on if they wanted. That would be the best of both worlds. The fact that the lightweight app exists means that JRiver has broken out quite a bit of code from the UI already. I don't know if there is anything in there that would be problematic as a service. Only they know for sure.

There may be valid reasons for keeping the wrong design (e.g. limited developer resources, other priorities, lack of demand, etc.) that justify the decision, but it doesn't make it less wrong.

If you want to say academically wrong, then fine I agree with you. However, if you put a bunch of application architects together in a room, they will tell you that things such as resources, priorities, user demand, scale, even perceptions are all detrimental to a good design. At the end of the day any software project is subject to a lot more than academics. Can you imagine how ridiculous a "hello world" program would be if it were subject to "correct" design? You could make it Object Oriented with separation into UI and data access layers. You could use a factory design pattern to allow multiple db's to be used to store the string etc. And lets make the db object a singleton so we don't accidentally create two... It may make it a "better" design but not a better program. In fact it would probably be worse given the complexity and likelihood of issues.

I also would like to see the lightweight portion available as an optional service. Discussing our opinions on application design although intellectually stimulating isn't going to get JRiver to make that change, so it would probably be best if we agree to disagree and drop it. One thing that is a fact is that the client/server portion has evolved significantly in the last couple of years in MC and it might be time for them to review the design and see if their choice is still applicable.

[babgvant]

A service runs all the time. The system tray application does not so it is going to use more resources when not in use on most users computers who don't run it full time. It's going to result in longer start up times as well. Of course the service portion could be made optional, then it wouldn't matter. A service is great on my HTPC, but not what I want on my other 2 computers. The system tray process at least gives users a choice.

Looking at what the current solution provides/requires I don't see any tangible, negative trade-offs versus running it as a service process. 

Both are:

- optional, server only components
- net neutral when it comes startup time (to be useful the Media Server component runs on user login), using "Automatic (Delayed Start)" might even boost the perceived startup speed v. the current solution
- net neutral when it comes to choice if the service is installed as "Manual" for startup, a similar amount of development effort to what was required to add the Media Server shortcut would be required to automate service control from the app.

Using a service gets:

- built in process monitoring
- built in recovery mechanism, including user defined actions
- headless operation
- freedom from UAC constraints (don't know if this matters in this scenario)
- remote management
- removes the risk that logging out will kill important functionality

If you want to say acemically wrong, then fine I agree with you. However, if you put a bunch of application architects together in a room, they will tell you that things such as resources, priorities, user demand, scale, even perceptions are all detrimental to a good design.

I think we must have different opinions of what constitutes "good design".  I also don't think one needs to seek refuge in an Ivory Tower to choose a service application in this scenario. 

At the end of the day any software project is subject to a lot more than academics. Can you imagine how ridiculous a "hello world" program would be if it were subject to "correct" design? You could make it Object Oriented with separation into UI and data access layers. You could use a factory design pattern to allow multiple db's to be used to store the string etc. And lets make the db object a singleton so we don't accidentally create two... It may make it a "better" design but not a better program. In fact it would probably be worse given the complexity and likelihood of issues.

That's an interesting perspective.  I would argue that all of that complexity ignores "correct" design given the requirements.

[Matt]

Like most things, this isn't a black and white issue.

The server components of Media Center rely heavily on the database.

Forking these components to a service would necessitate communicating with the database using IPC.

Adding a layer of IPC to the most speed-sensitive part of the program would be a performance compromise.

We may disagree about which priority is more important (performance vs cleaner UI / backend separation), but there certainly isn't a "correct" and "incorrect" answer.

[babgvant]

Like most things, this isn't a black and white issue.

The server components of Media Center rely heavily on the database.

Forking these components to a service would necessitate communicating with the database using IPC.

How do you resolve this now?  Aren't there already two processes and you support discrete client/server PCs?

Adding a layer of IPC to the most speed-sensitive part of the program would be a performance compromise.

We may disagree about which priority is more important (performance vs cleaner UI / backend separation), but there certainly isn't a "correct" and "incorrect" answer.

Doesn't that depend somewhat on how noticeable the performance hit is?  Even if there are 100K items being indexed we aren't talking about that much data.  Given that, there are ways that you could work with the dataset w/o a lot of IPC.

Stability isn't always free, but if MC want's to compete in the DVR space it has to be near the top of the requirements list.

[babgvant]

Even if there are 100K items being indexed we aren't talking about that much data.  Given that, there are ways that you could work with the dataset w/o a lot of IPC.

Did some more thinking on this and I don't see why you couldn't hit both requirements by loading a quasi read-only database into each client process and use IPC messages to push changes to the clients (I am treating the UI on the server PC as a client).  This is all based on the assumption that aside from the initial media import process there are relatively few writes and it is OK for any CUD to be "slow".

Since there are no actual writes except in real db maintained by the service even if a client had a breakdown of some sort (missed message, delayed processing, etc) the impact would be very limited.  Interactions in the client UI that caused an update (i.e. metadata changes) would would be a bit slower than they are currently, but I doubt that it would be too painful unless you're running really slow hardware - and if it were unacceptable, the change could be made asynchronously.

[csimon]

It's not going to happen, because it's a major restructure and rewrite, but ideally there would be 3 components...

JR Server - holds the database and responds to requests from clients; allows multiple instances of the database ("library")
JR Manager - connects to a library on a server and provides ripping, tagging, setting up views etc
JR Player - connects to a library on a server and provides browsing of the library and the playing and rendering of items, including the ability to act as a controller for another Player instance or DLNA device

I think Twonky and Plex already take this approach, or are nearing this model?

And it's only the Player really that would be dependant on the operating system and its UI and media-playing facilities, so it paves the way for the Server to be put on NAS units!

Speed of response is not going to be an issue.