jellyfin / mopidy-jellyfin

Jellyfin Extension for Mopidy
https://jellyfin.org
Apache License 2.0
93 stars 16 forks source link

Extension and Backend are Loading but I'm not getting a front-end #114

Closed tokenwizard closed 2 years ago

tokenwizard commented 3 years ago

I'm trying to run Mopidy on a Raspberry Pi 3 B+ with the mopidy-jellyfin extension. Initially I will just run as my "pi" user and once I have that working I can copy my configs over so I can use the systemd service.

When launching mopidy, it seems like it loads the Jellyfin extension, but I'm not seeing anything related to Jellyfin on the Web Interface. Is there somewhere else I should be looking? The documentation on configuration and use is pretty sparse, and I would be glad to contribute to it once we get to the bottom of this.

I did find that it seems to put the jellyfin extension config file here (when installing/running as user): .local/lib/python3.7/site-packages/mopidy_jellyfin/ext.conf

Here is the terminal window where I'm running Mopidy: image

But this is all I see when I go to the Web Interface: image

Is there somewhere else I should be putting my jellyfin config files? When running as a Service, it seems to look in these two paths for config files: /usr/share/mopidy/conf.d /etc/mopidy/mopidy.conf

But for running as a user, all documentation I've found points to the ~/.config/mopidy folder.

tokenwizard commented 3 years ago

Hmm, So maybe it just does not show in the http frontend? I installed the mopidy-mobile Web frontend and I was able to get to the Jellyfin library.

Is there a recommended frontend for primarily using Jellyfin?

tokenwizard commented 3 years ago

Also, to help out any other newbs like myself who may stumble on this; here is a screenshot of where the various config files seem to be located for both the user configs and the systemd/service configs: image

mcarlton00 commented 3 years ago

There's several things to unpack here, but I think you've gotten yourself twisted around and very confused.

First off, there's almost no situation that you should ever be touching files of the python packages themselves (anything in a dist-packages or site-packages directory). Those are meant to be managed by either pypi or your package manager and messing with them could prevent future updates from working properly.

The config file that you should be populating is either $HOME/.config/mopidy/mopidy.conf for a user deployment or /etc/mopidy/mopidy.conf for a systemd/service deployment. There's some documentation about this in the docs page.

To my knowledge, every frontend should work fine. I've been through most of the http frontends and never saw this issue before, but i primarily use mopidy-mpd and ncmpcpp for my usage.

I can't say for sure, but I would guess that whatever you've done in the python package directory is causing incompatibilities somehow, but I can't imagine how that's possible. But as I said, there's no reason for a user to ever be in those directories.

tokenwizard commented 3 years ago

So, when I install a plugin via pip to use with the service, ie: sudo python3 -m pip install mopidy-jellyfin

The config options for Jellyfin would not show up in the main config file (/etc/mopidy/mopidy.conf) nor did a jellyfin-specific config get populated in /usr/share/mopidy/conf.d

It was not clear to me from the main Mopidy project documentation whether there was a need to manually create each of the plugin-specific config files and add them to the conf.d folder, or to add the appropriate configuration sections to the mopidy.conf file.

I do see that the mopidy-jellyfin documentation makes that more clear, at least for the case of this particular extension.

Thanks!

mcarlton00 commented 3 years ago

I don't really use many of them, but I'm not aware of any mopidy extensions that automatically create a config file or populate the main config. In my opinion, doing so would also be a poor design decision, as it could have unintended side effects on a system. In general, most mopidy extensions will throw errors if they haven't been configured, and since many extensions would require login credentials to a third party system having a default config is not a straightforward thing.