shmooo 0 Posted June 18, 2022 Share Posted June 18, 2022 (edited) Theater using the default mpv.conf causes unnecessary conflicts. I'm using a pretty complex mpv.conf and some options like simply setting `vo=gpu` breaks Embys whole playback ui. The fix to that would be to call mpv with `--config-dir=/emby/config/dir` see https://mpv.io/manual/master/#options-config-dir Is there a reason why Emby is using the system wide mpv.conf instead of it's own? Edited June 18, 2022 by shmooo Link to comment Share on other sites More sharing options...
generiq 113 Posted June 18, 2022 Share Posted June 18, 2022 7 hours ago, shmooo said: I'm using a pretty complex mpv.conf and some options like simply setting `vo=gpu` breaks Embys whole playback ui. This is because of electron and has nothing to do with the mpv.conf. Link to comment Share on other sites More sharing options...
shmooo 0 Posted June 18, 2022 Author Share Posted June 18, 2022 (edited) 12 minutes ago, generiq said: This is because of electron and has nothing to do with the mpv.conf. Yes, emby not working with vo=gpu is caused by electron. That doesn't change anything I said, though. There is just no need to use the users mpv.conf when emby could just use its own. It just doesn't make sense. Nobody from the Emby team knows how poeple have configured mpv on their system and all it does is create inconsistencies in user experience and in the worst case crashes. I could have an empty mpv.conf or I could have 200 lines long config with very specific settings for my usecase. Emby just does not need to depend on my settings. There is no benefit and only negatives in doing this. All they'd need to do to get rid of this is set $MPV_HOME to somehting not default. Edited June 18, 2022 by shmooo Link to comment Share on other sites More sharing options...
generiq 113 Posted June 18, 2022 Share Posted June 18, 2022 It wouldn't change anything. The commands are being set directly from the emby scripts. They would have to provide options to omit any commands they are wanting to use, like with the hardware acceleration option to allow use of the mpv.conf. There are a number of options that are getting set in the background that you aren't aware of. Things that help with the server interaction. I personally don't get any conflicts, and I have quite a complicated mpv.conf, multiple confs, actually. That said, some time ago, I did make the suggestion to have a text box in the Theater UI that would write directly to an mpv.conf for us to configure. But to recap, even if emby used its own mpv.conf, nothing would change. mpv would behave exactly the same. It's all quite moot anyway. Eventually, they will be removing mpv and will no longer use it... Link to comment Share on other sites More sharing options...
Luke 37376 Posted June 18, 2022 Share Posted June 18, 2022 8 minutes ago, generiq said: Eventually, they will be removing mpv and will no longer use it... Well, not for Linux and older versions of Windows. mpv will be sticking around for those. Link to comment Share on other sites More sharing options...
shmooo 0 Posted June 18, 2022 Author Share Posted June 18, 2022 11 minutes ago, generiq said: It wouldn't change anything. The commands are being set directly from the emby scripts. They would have to provide options to omit any commands they are wanting to use, like with the hardware acceleration option to allow use of the mpv.conf. There are a number of options that are getting set in the background that you aren't aware of. Things that help with the server interaction. This is just plain wrong. It would change everything since Emby would not interfere with mpvs config anymore. It would not dictate anymore, what user can and can't add into their default mpv config. The fact that you don't have any conflicts doesn't mean anything. Also, there is not one single reason to read and use users default mpv config. It just breaks things and that is all. Also again, I don't know why you keep making up stuff. Just try it yourself. Run theater with $MPV_HOME set to any directory that is not mpvs default config dir and it will not use your config anymore and thus will not have any incompatibilities with whatever config options one has set in there. 15 minutes ago, generiq said: It's all quite moot anyway. Eventually, they will be removing mpv and will no longer use it... What really is moot, is this point because all that means is that emby does not work right now. At least not without workarounds that should absolutely not be necessary! 7 minutes ago, Luke said: Well, not for Linux and older versions of Windows. mpv will be sticking around for those. Thanks for the reply. So is there anything I am missing here? Why not just ignore mpv default config on users system? Link to comment Share on other sites More sharing options...
Luke 37376 Posted June 18, 2022 Share Posted June 18, 2022 5 minutes ago, shmooo said: This is just plain wrong. It would change everything since Emby would not interfere with mpvs config anymore. It would not dictate anymore, what user can and can't add into their default mpv config. The fact that you don't have any conflicts doesn't mean anything. Also, there is not one single reason to read and use users default mpv config. It just breaks things and that is all. Also again, I don't know why you keep making up stuff. Just try it yourself. Run theater with $MPV_HOME set to any directory that is not mpvs default config dir and it will not use your config anymore and thus will not have any incompatibilities with whatever config options one has set in there. What really is moot, is this point because all that means is that emby does not work right now. At least not without workarounds that should absolutely not be necessary! Thanks for the reply. So is there anything I am missing here? Why not just ignore mpv default config on users system? I guess it's just never come up before. The way it currently is is based on user feedback Link to comment Share on other sites More sharing options...
shmooo 0 Posted June 18, 2022 Author Share Posted June 18, 2022 Yeah, this was not an attack. I'm just in disagreement with the other poster. This was really meant more like as a bug report. The fix is super simple. You just have to set MPV_HOME to something like `$XDG_CONFIG_HOME/Emby Theater/mpv` and it's windows %appdata% equivalent and thats it. Users who still want to use an extended mpv.conf are then able to place one there specifically for emby. Link to comment Share on other sites More sharing options...
generiq 113 Posted June 18, 2022 Share Posted June 18, 2022 Just now, shmooo said: Why not just ignore mpv default config on users system? So you want to remove the ability to use ANY mpv.conf!?!?!?!?!!? That's insanity! How would you configure mpv? You can't put all of the options in the UI!!!!! I think you are confused about something. 4 minutes ago, shmooo said: Also, there is not one single reason to read and use users default mpv config. It just breaks things and that is all. This is what is wrong! I'm actually not fully understanding what you are trying to accomplish. If you only have one mpv.conf, there can't be any conflicts. It will either work or not work, with no breakage. If you use mpv separately and have another mpv.conf, just make that portable and again, there will be no conflicts. Link to comment Share on other sites More sharing options...
shmooo 0 Posted June 18, 2022 Author Share Posted June 18, 2022 Just now, generiq said: So you want to remove the ability to use ANY mpv.conf!?!?!?!?!!? That's insanity! How would you configure mpv? You can't put all of the options in the UI!!!!! You just have no clue what you are talking about and it is showing Link to comment Share on other sites More sharing options...
generiq 113 Posted June 18, 2022 Share Posted June 18, 2022 Just now, shmooo said: You just have no clue what you are talking about and it is showing I build my own mpv, and have multiple configs.... Link to comment Share on other sites More sharing options...
shmooo 0 Posted June 18, 2022 Author Share Posted June 18, 2022 And nobody is stopping you from doing that. So maybe just try to educate yourself before you make arguments that do not make any sense at all Link to comment Share on other sites More sharing options...
generiq 113 Posted June 18, 2022 Share Posted June 18, 2022 Just now, shmooo said: And nobody is stopping you from doing that. So maybe just try to educate yourself before you make arguments that do not make any sense at all lmao.... ok sweetie! Link to comment Share on other sites More sharing options...
shmooo 0 Posted June 18, 2022 Author Share Posted June 18, 2022 1 minute ago, generiq said: lmao.... ok sweetie! You are just wrong. If this makes you feel better about it, instead of just admitting it, then whatever.. Link to comment Share on other sites More sharing options...
generiq 113 Posted June 18, 2022 Share Posted June 18, 2022 1 minute ago, shmooo said: You are just wrong. If this makes you feel better about it, instead of just admitting it, then whatever.. Ok, so give me an example of a breakage that happens when using a conf the way it is currently set up. The UI issue has nothing to do with the conf, so a better example is needed. Hey! Maybe I'm missing something??? Stranger things have happened. Link to comment Share on other sites More sharing options...
shmooo 0 Posted June 18, 2022 Author Share Posted June 18, 2022 You should really just stop. I posted all the info you need to replicate this. And not only that, but also the logical und sensible fix to the exact problem. It is never not a bad idea to rely on a random configuration file you have no control over as a developer. And there is again, not one single reason to use the systems/users default config files for emby. They are shooting themselves in the knee by doing this, because it causes unwanted und anpredictable behaviour. What it all comes down to is, you do not understand what a process and a process environment is and how the childprocess, in this case mpv, inherits it's parent environment. So at this point, this discussion is over from my side. I made my point and I'm pretty sure, anyone with even the slightest understanding of how all of this works will agree that this is a pretty bad idea and should be fixed. Especially since there is literally zero downsides in doing this. Link to comment Share on other sites More sharing options...
generiq 113 Posted June 18, 2022 Share Posted June 18, 2022 I think I understand what you want, now. It isn't that it's breaking functionality, you would just prefer the mpv.conf to be exclusive to Theater, and can't be affected by external confs. Am I understanding that correctly? Several years ago, there was a developer that was writing for Theater. His personal choice was to make the conf portable and keep it exclusive to Theater. At this time, many people had written their own mpv.confs, and I advised against changing what was already established. He initially didn't understand my suggestion. A little while later, multiple users were complaining that their configs weren't working and were confused as to what was happening. That developer then realized why I made the suggestion, and stopped doing it. You and I have much understanding of the mechanics of mpv, but the majority won't, and problems will occur. This is why I also made the suggestion to Luke that there be a text box in the UI to write an mpv.conf. Then the conf could be contained and isolated within Theater, and people could easily write a conf without confusion. This would fill your request, yes? Link to comment Share on other sites More sharing options...
generiq 113 Posted June 18, 2022 Share Posted June 18, 2022 Also something to consider. And portable_config doesn't work with libmpv Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now