Media Player Classic Remote Control for Media Browser {EXPERIMENTAL}

[bfir3 117]

I'll be honest, I haven't updated my Emby server in quite some time just so that I could retain the functionality of the original MPC remote with simple setup that can easily be associated per user. I'm looking forward to updating to a new stable release soon as the database and other changes seem significant. I hope you can find a nice solution to assign sessions per user. Just having this simple app on any windows PC allows my users to direct stream pretty much all content whereas they would normally have to transcode most of it. It is absolutely essential for my setup, and I want to extend my thanks to you for creating this wonderful little app.

[anks 36]

@@bfir3, means a lot thanks.  @@Luke can we make this work somehow for those that depend on this app?  Option to impersonate users perhaps as suggested above.

[anks 36]

Alternatively, we could tie this to a single user and use that API Key, would that cause most folks an issue?  No ideal I know but easily achieved.

[bfir3 117]

I don't know about the complexities, but the best part about the app in the state that I use it is that I can run it on any windows machine, and any web client that connects to it will have their user associated to it when playing to the device. If the app is tied to only one specific user or requires an API key that is only accessible from the admin panel then it is significantly less useful (only good for personal use, but not for those who share access to the server).

[Happy2Play 9317]

Any one seeing an Unhandled Exception from MPC Remote?  Pretty sure MPC Remote was the cause, because as soon as I closed the process and re-opened it the error went away.

 

Server remains running until error is acknowledged then server task dies.  Just happen to noticed it on the machine during an update.  Looking at available logs it shows in 5903-5905.

Error Main: UnhandledException

Value cannot be null.
Parameter name: deviceName

[zebo51 19]

At this point I would like this functionality back.  Once this broke I tried Emby Theater and it just seems really buggy to me and doesn't work very well for my needs or setup.  Playing via the browser doesn't work anymore for 5.1 setup either, so I was down to using this MPC pluggin.  It all went to crap it seems in a months time.  5.1 stopped working watching using Chrome and FF.  Then this plugin stopped.

 

Thanks

[Happy2Play 9317]

At this point I would like this functionality back.  Once this broke I tried Emby Theater and it just seems really buggy to me and doesn't work very well for my needs or setup.  Playing via the browser doesn't work anymore for 5.1 setup either, so I was down to using this MPC pluggin.  It all went to crap it seems in a months time.  5.1 stopped working watching using Chrome and FF.  Then this plugin stopped.

 

Thanks

 

MPC Remote working fine here with beta v3.0.5920.0.  Are you using the version from post 57 and assigning a api key?

Edited March 26, 2016 by Happy2Play

[bfir3 117]

Any luck with bringing this back to the way it was working before the API key requirement?

[Happy2Play 9317]

Any luck with bringing this back to the way it was working before the API key requirement?

What is wrong with it with api requirement?  I see no difference with MPC functionality as before assigning it a key.

[bfir3 117]

What is wrong with it with api requirement?  I see no difference with MPC functionality as before assigning it a key.

Well, maybe the issue is resolved in later Emby server versions, but when using the app with the API key, I was only able to get a key for a user that was an Admin. The API key was only obtainable through the Server dashboard, and this key was not uniquely assigned to a user indefinitely. Because of this, I stopped updated my Emby server so that I could at least maintain the simplicity and ease of use of the original 1.0.1 MPC remote. 

 

If later Emby server versions have made it so that any user can easily access their unique API key which they can use with MPC remote, then I will definitely consider updating, even though the 1.0.1 method is still preferred due to it's simplicity. It may not seem like a lot to acquire and enter an API key, but for users who just want to watch stuff that are used to Netflix, it can cause a barrier to entry. In 1.0.1 there is no need for the user to gather any information or data from another source. Run it, enter the server address, good to go.

 

Please advise me though if more recent Emby server versions have made that API key easier to obtain. I have been following the development, and I would love to be able to take advantage of the new database changes and optimizations. I would probably lose my existing user data when updating, but I'll worry about that later.

[zebo51 19]

MPC Remote working fine here with beta v3.0.5920.0.  Are you using the version from post 57 and assigning a api key?

I downloaded the file unzipped and then got my API key.  Does this not have an install?  Do I just place the folder somewhere?  I looked for my original and all I have is a file on my desktop and in my startup folder.  I can't seemed to find an install directory.

 

Thanks

[daedalus 430]

Do I just place the folder somewhere?

 

yes extract anywhere you want and just run the exe

runs here without an issue

 

the installer installs it somewhere in your appdata folder if i remember right

[zebo51 19]

MPC Remote working fine here with beta v3.0.5920.0.  Are you using the version from post 57 and assigning a api key?

 

 

yes extract anywhere you want and just run the exe

runs here without an issue

 

the installer installs it somewhere in your appdata folder if i remember right

 

Great, it seems to be working.  Thanks to you both for your help.

 

On another note, I saw another post on this but no answer.  Is there a way to make this my default player device?

[bfir3 117]

Well, maybe the issue is resolved in later Emby server versions, but when using the app with the API key, I was only able to get a key for a user that was an Admin. The API key was only obtainable through the Server dashboard, and this key was not uniquely assigned to a user indefinitely. Because of this, I stopped updated my Emby server so that I could at least maintain the simplicity and ease of use of the original 1.0.1 MPC remote. 

 

If later Emby server versions have made it so that any user can easily access their unique API key which they can use with MPC remote, then I will definitely consider updating, even though the 1.0.1 method is still preferred due to it's simplicity. It may not seem like a lot to acquire and enter an API key, but for users who just want to watch stuff that are used to Netflix, it can cause a barrier to entry. In 1.0.1 there is no need for the user to gather any information or data from another source. Run it, enter the server address, good to go.

 

Please advise me though if more recent Emby server versions have made that API key easier to obtain. I have been following the development, and I would love to be able to take advantage of the new database changes and optimizations. I would probably lose my existing user data when updating, but I'll worry about that later.

 

Can anyone advise me about this? I just want to know if regular users can easily access their API key or not in the latest Emby Server versions. If it's still not possible, then the app loses a lot of desirability, and I would want to stay on my Emby Server build from when the app worked without the API key.

[Luke 39422]

You can create api keys in the server dashboard

[Happy2Play 9317]

Currently is appears it is not recording the play state.  At least for me.

Edited April 13, 2016 by Happy2Play

[bfir3 117]

You can create api keys in the server dashboard

 

Which means normal users have no way to use this app on their own (that is, without an admin supplying them an API key)? Damn, that's too bad. I'll have to keep holding out hoping for this to change.

[Luke 39422]

Well blame the people who exploit even the slightest vulnerabilities. I had to close the loophole that this was using, and I have not had a chance to customize the api key creation process to restrict privileges. 

 

FYI - if you're waiting for this to magically start working, that's not going to happen. One of two things is going to happen - either I will do the work above to customize the api keys, which yes, will require you to send a key to a user. Or, since this is a user-facing application, the app can just have users login and that also solves the problem, with no need to send api keys. A third option still is a true web interface plugin that can communicate with his app and pass along the security info, much like the mobile apps do with Chromecast. That also requires work from Anks.

[bfir3 117]

Well blame the people who exploit even the slightest vulnerabilities. I had to close the loophole that this was using, and I have not had a chance to customize the api key creation process to restrict privileges. 

 

FYI - if you're waiting for this to magically start working, that's not going to happen. One of two things is going to happen - either I will do the work above to customize the api keys, which yes, will require you to send a key to a user. Or, since this is a user-facing application, the app can just have users login and that also solves the problem, with no need to send api keys. A third option still is a true web interface plugin that can communicate with his app and pass along the security info, much like the mobile apps do with Chromecast. That also requires work from Anks.

 

I'm not blaming anyone, or expecting anything to "magically" happen. I will continue to wait patiently as I understand that development on these features takes time, and resources are spread across a variety of desired features, not just this one. I appreciate the time that you and other devs put into the app, along with community members who develop 3rd party apps like this one!

 

That being said, I think the idea of having users login to the app makes a lot of sense and could be really great. I think doing this, it would tie the device to a specific user, which means that only that user would be to see and control that device (unless they were an admin with privileges to control any devices). This would be an even better solution to the previous method where the app just needed to be running, and any user could connect to any app that was running on any users machine.

 

If the source code was disclosed for this app, I would be interested in taking a look to see about implementing the user login feature.

[Luke 39422]

The most seamless option is the third one, because no extra login is required, but as mentioned that requires both an app and a plugin. The login option is a nice compromise that reduces the work required in exchange for requiring the user to login.

[bfir3 117]

The most seamless option is the third one, because no extra login is required, but as mentioned that requires both an app and a plugin. The login option is a nice compromise that reduces the work required in exchange for requiring the user to login.

 

Would the third option limit the ability of clients to connect to an app that is running on someone else's machine? I like the idea that the login option could tie the app to a specific user and prevent control of the app from other users. And the app could potentially remember the user login information, so that they only need to enter it once.

[anks 36]

@@bfir3 The app originally used a Login and worked the way you described, however there are limitations with this approach, namely that all played content, resume history was tied to one user.  It was also more info for the user to input, there should even be screenshots at the beginning of this thread.  I therefore exploited a security flaw in the original ChromeCast implementation which I was very transparent about and expected it to be closed but worked in the way that suited everyone.  

 

Using an API doesn't tie control to a single user but also doesn't save play history etc,  it is also more secure since by generating an API key an admin is effectively granting the app permission.  I don't think security is a key issue with app anyway since you need an Emby login anyway to use it.

 

The code is not tidy at the moment but the authentication piece is described in this thread, it's very easy with the API.  If you want to work with me on improving the app, you're very welcome.

 

@@Luke, can you comment more on what would be required for to use the same security approach as the ChromeCast?  Also could a security token/sessionId not be passed with the remote control request?  

[bfir3 117]

@@bfir3 The app originally used a Login and worked the way you described, however there are limitations with this approach, namely that all played content, resume history was tied to one user.  It was also more info for the user to input, there should even be screenshots at the beginning of this thread.

 

Oh I see, interesting. I'm curious why tying all the played content and resume history to one user is a bad thing? Isn't that the way it should be, and currently works anyway? If I stream to the app from my user account, I would want the resume history and played content to only appear from that account anyway (which is what occurs presently).

 

Or am I misunderstanding and maybe you mean something more along the lines that the app was tied to a specific user by logging in, but that any user could control it (despite not being the user that logged into the app) and that the played content and history would only be tied to the user that was logged in on the app and not the user that was controlling it?

 

edit: By the way, I very much appreciate the discussion and responses from you guys on this topic!

 

edit2: Hold up a second here! I just checked out the new update for Emby Theater and it looks like you've introduced the option to stream to an external player! This is exactly the kind of functionality that this media player app is trying to achieve. I'm guessing that this feature is only available from the Emby Theater app, and maybe from the web version at tv.emby.media as well? If this could be integrated in the normal web client, it would do away with the necessity for an app like this!

Edited April 13, 2016 by bfir3

[bfir3 117]

 

 

the web version cannot launch programs so you will need the installed windows version for that.

 

Ah, I just saw your comment about the Emby Theater update, Luke. I remember you mentioning something about that in the past, and realize now that this is likely the case for any web version. In that case, this app is still the way to go!

[Luke 39422]

FYI - if anks wanted to build an emby theater plugin then it would also work for the web version as well. all he has to do is embed an http server into his app and then the web plugin can talk to it. no extra login would be needed in that scenario.