Just a curiosity question

I am very happy with Mopidy + SnapCast as my multi-room audio solution. I am very grateful for all of the people who spend their free time making my life better. Thank you all!

My progress is probably slower than it ought to be because although I do IT for Windows machines, I have an ancient BS in Computer Science, a history as a C/C++ programmer and I have a passing familiarity with Unix, I have not been immersed in the environment. A house, a career and a dog tends to eat into one’s time, which makes me all the more appreciative of the people who move this platform forward.

Now on to the stupid question: What does Mopidy use as a LAMP stack?

I ask the question because it took me several hours to get Mopidy Local SQLite to work. In the end, I think installing SQLite3 and reinstalling Mopidy Local SQLite (many other bad avenues followed) resolved the issue (“mopidy[396]: WARNING Local library sqlite not found” and mopidyclt local scan failing for much the same reason).

I assumed that since Mopidy probably has some sort of SQL solution as part of its foundation that Mopidy Local SQLite would utilize it for its own needs. It may well. God knows my “production” and “experimental” servers both have a colorful history. I just know that finding information on the foundation on which Mopidy is built is fairly difficult to find if you haven’t set up a development environment (which is in my near future).

This is obviously a low priority question since I appear to have gotten past my issues.

As an aside, what I’m not happy about with Mopidy Local SQLite is that while it provides a lot of wonderful resources for looking at the locally available content, it appears (little time playing with it) to not give a way to look at the library as presented via the local file structure, which is familiar for me and is likely to remain that way.

*** Added: That’s just a first impression. My issue is that I have a fair amount of world music that comes from compilation albums. I have those segregated out in my file structure. There are other things that I like about my file structure. All of that appears to be stripped out by Mopidy Local SQLite. I am certainly not suggesting that I’m a main line user and this would be a common concern, but at this moment it makes me unhappy with Mopidy Local SQLite as my only way of viewing the library. Perhaps this is that use case that moves me into development. ***

Those niggles aside, a sincere thank you to all of the developers and users who are helping me achieve a system that satisfies my goals. It continues to impress me how good this is.

There’s no built-in LAMP stack in Mopidy. Local SQLite itself is an extension built on top of Mopidy, not a built-in feature.

If no plugins are installed to handle the local collection then Mopidy will store the collection meta-info in a local JSON file (no relational databases involved).

Same for the web stack: Mopidy supports a quite wide set of web extensions (Iris, API Explorer, Moped, Mobile, Mopify etc.) but it’s really agnostic when it comes to which one you decide to use - or if you decide to use one at all. It will just provide you with the possibility of exposing an HTTP port and will provide you with a basic JSON-RPC API, and then as long as you’ve got a web extension installed in the proper place it will simply run it.

So in a nutshell you can really see the Mopidy core as a minimal skeleton powered by the extensions that are built on top (and which ones the user decides to use), more than a monolithic architecture that can be modelled as a LAMP stack or any similar monolithic stack.

Thank you very much for the illuminating information.