Linux Server Support

[jmediamanager]

Reported by adam.keun, Mar 13, 2013

Hi just wondering if there is any plans for having linux support for the JMM server?

Apr 21, 2013 dominik.karadeniz

Yes, that would be great. I am dreaming of integrating it in my server setup, with transmission, xbmc.

Everything works like a charm now and is fully automated, but handling anime is still poor. I hope to change that with jmm. Unfortunately, being a windows application severely limits its use cases and modularity.

May 15, 2013 Craige1Emmott

I can tell you now this probably wont happen any time soon. JMM as a whole is completely built around MS technologies. Anything running on Linux will ether require mono or a complete rewrite. Even the API used for communication is a MS technology. It would take one skilled Linux dev with some serious dedication to make this happen.

May 15, 2013 adam.keun

I had a feeling it was built around MS, tis a shame because it's such a great program and I would have loved to integrate it with my linux machine.

[jmediamanager]

This will be investigated. It is possible, but does involve a a re-write of a large chunk of JMM Server

[gibwar]

This is my long term goal for the server if possible, to decouple it from the WPF foundation and enable it to use the technologies that the Mono Project support, which is quite a lot actually (just no WPF and poor WCF support).

The other portion is to create a stable Web API that can allow for other integrations as well as extensions that should be powered by the ASP.Net Web API platform that can then run off of Microsoft's cross platform Project K and ASP.Net vNext.

Believe it or not, Microsoft is working on a cross platform ASP.Net engine, even hosted here on GitHub! This is planned to be released with Visual Studio 2014 and doesn't even require Visual Studio, check out this post by Scott Hanselmann introducing ASP.NET vNext and even how to develop ASP.Net vNext applications on Mac as well as seeing the new tooling for this included in Visual Studio "14" CTP3 (they're really changing things up). If you can't tell, I'm just a little excited with the direction of Microsoft with Project K.

With all of this, I think we can finally take JMM cross platform with reasonable performance and enable the server to run on Windows, Mac, or Linux.

That's my goal anyway.

[maxpiva]

IMHO, a good approach right now, is moving all the GUI functionality from the Server to the Desktop. And make the server a service, a black box. This will decouple WPF from the server. Next... Contracts should be refactored to a better approach (maybe rest + json), and reduce the amount of data they carry. We should study also the possibility of having multiple servers, in a master->slave fashion.

[gibwar]

That was part of my idea, remove all UI from the server component and move what little configuration needs to be done to a web page. It would only allow the simplest of configuration to get the server up and running. The Web API provides a solid foundation for providing a REST json interface. It would be nice if the API was accessible enough to allow a different front end than just JMM Client, MA3, and AnimeBuddy.

[jmediamanager]

My opinion on staging this project

NOTE - I think ASP.NET vNext should be separated out from this.

Stage 1

Remove reliance on WCF, by using RESTful services. We don't need to say just JSON. It is easy enough to create RESTful web services that support both json/xml. The reason I say this should be done before removal of the UI, is because the methods required to administer the server should be RESTful methods

Note - This may take a lot of re-work on JMM Desktop and MA3

Stage 2

Remove UI from JMM Server. Allow all configuration from JMM Desktop. Allow JMM Server to run as a service

Stage 3

Determine whether JMM Server is now linux compatible. Make any further changes to facilitate this

[OzWookiee]

Can I add a huge +1 here guys. Been a looooooong time user since inception when it was just a MediaPortal plugin but would love to move my home server to a linux server to get more out of aging hardware.

[CatmanIX]

I'd also like to add a +1 while i'm here.

[bmfrosty]

+1. Would love to get this going in a docker container on my UnRAID box. Would love to not have this running on m desktop.

[bigretromike]

+1 Yeah. I can just image how many more people would start using this thanks to Linux support!

[d3xMachina]

+1 don't let this project die please, my raspberry needs you :(

[bigretromike]

both hasher and JMMServer project is not compatible with MONO out-of-box

[bigretromike]

Stage 1: Is on the way. Just to update you guys.

[CatmanIX]

Thanks for the update Mike, glad to hear this is coming!

[bmfrosty]

Very exciting.

[counterfit]

Out of curiosity, how many stages are there?

[da3dsoul]

3 major stages, more substages.

[bigretromike]

First stage was the hardest to enforce and still need some polish also with it webui have been started , second stage - stripping server out of ui and moving it to console/service is easier, the third stage should be on medium level as moving console/service to mono/core.

[bmfrosty]

Any updates? I'm super interested on how close you're coming on stage 1.

[da3dsoul]

Network communications are now cross platform implementations. A webui is in the works as well. It's coming along, slowly.

[bigretromike]

network communication was always cross platform... but now it use proper api webui is limited to act as "gui" for server server is not close to be cross platform unitl everything is fixed.\ client is remade to v2 for windows only

in current situation 1+ year (to having shoko server on linux)

PS. Please correct me if I am wrong (I hope I am)

[bmfrosty]

Will the webui eventually replace the client, or is it planned to be continue to be client/server based?

[ElementalCrisis]

Nope, WebUI is just a replacement for the Server UI so we can make server headless. We have no plans for a Linux client.

[bigretromike]

there will be open gate for all clients, with open apiv2 you could make any client you want... as main leader ElementalCrisis support windows only clients. - which I dont mind, as I hope for cross-server

Imo, if there ever be a working cross platform server there will be 1- or 3-rd party client for other platforms anyway.. it will be matter of time...

[Jimmyson]

Considering that platform currently uses either SQLite, MySQL and SQL Server as options, would the installation method have the ability to trigger the use of a particular dependency by user entry, or will one be automatically chosen?

Or would this SQL setup be an isolated installation from the primary Linux package install...

[bigretromike]

from one point of time the main developer @maxpiva wanted to drop those sql for one RavenDB or something similar. How that is related to current situation is beyond me right now

If its no the case then proper package wont be used as dependency as shoko use what ever you put in config and the database don't have to be on same host. So installing shoko without database is also an option. But that is to early to say anything...

[da3dsoul]

@bigretromike we are one step closer!

[Cazzar]

Currently Todo, there are still some issues to resolve code wise

Pri.longpath is completely incompatible with Linux Still some UI references in the logic DLL. CLI exe

[ElementalCrisis]

We need Pri.longpath for Windows, maybe there's a similar library we can use for Linux? If not I guess Linux well be restricted to its default path length for import folders.

[bigretromike]

Linux don't have the limitation windows has ;-) you can detect os, and load proper library

[bmfrosty]

I believe the Linux limitation is 255 bytes in filename, and 4096 bytes in path.

On Thu, Apr 20, 2017 at 12:56 AM, BigRetroMike notifications@github.com wrote:

Linux don't have the limitation windows has ;-)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/japanesemediamanager/ShokoServer/issues/52#issuecomment-295618549, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB8DjBS4o-JC0bkvZq2sTnBPHdftSu1ks5rxw-_gaJpZM4CYrXG .

[Cazzar]

That's a limitation at the filesystem level anyway, so there would be no use adding workarounds for it. Currently I am in the design stage on how we want to work around Pri.LongPath on mono, preferably keeping a single exe for feature matching.

[bigretromike]

it could have `function check_path' or similar that would repleace all pri.longpath or something and all the logic checking filesystem and/or platform would be there.

[Cazzar]

Right now I am just making a drop-in fork for pri.longpath that diverts to System.IO as looking at the other options, it would make a lot more boilerplate code to add in the long run.

[Cazzar]

Some good news for those wanting linux port Soon

@bigretromike you will like this one.

No setup UI, some functions of cloud are just broken, and this is my first run. SQLite is also broken. Not too sure about most functions as well.

Some changes have to be made to support it as well, for example, NutzCode.CloudFileSystem/AuthorizationFactory.cs#L28 needs to use string dirname = Pri.LongPath.Path.GetDirectoryName(Uri.UnescapeDataString(uri.Path).Replace("/", $"{System.IO.Path.DirectorySeparatorChar}")); else the server crashes on boot.

[Cazzar]

Fyi, code isn't in master as I had to break some of the cloud stuff to get it to boot on Linux, currently working out a fix.

[bigretromike]

@Cazzar that screenshot made me hard.... You did well comrade ... now throw me the sh!t repo url and lets the party started

its the best Shoko screenshot posted since JMMage

[Cazzar]

It's a bit of a confusion as I'm operating off a custom built pri.longpath that isn't being built against, I'll add it so it'll work soon, most likely in a "linux" branch

[bigretromike]

so basicly you needed to modify pri.longpath. can we add it then to our repo so we maintain it and update if ever needed ? @maxpiva will you update code in that nutzcode thing?

[Cazzar]

Nutzcode has already been done via da3soul, and for having the pri.longpath, we'd need a repo preferably

On Tue., 25 Apr. 2017, 5:47 pm BigRetroMike, notifications@github.com wrote:

so basicly you needed to modify pri.longpath. can we add it then to our repo so we maintain it and update if ever needed ? @maxpiva https://github.com/maxpiva will you update code in that nutzcode thing?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/japanesemediamanager/ShokoServer/issues/52#issuecomment-296946736, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8rprhdtKcQeE_rMCho4-SjZagsti2nks5rzaT_gaJpZM4CYrXG .

[bigretromike]

@ElementalCrisis you heard the man, please make repo for him

[Cazzar]

MSSql seems painfully slow on linux, looking at mysql performance, on the side of acceptable.

[Cazzar]

https://github.com/japanesemediamanager/ShokoServer/tree/linux @bigretromike

[bigretromike]

finally something I will have fun working on ;-)

[bigretromike]

do we have issue/project with what is working what isin't or what to check in first run ?

[ElementalCrisis]

@Cazzar posted some info on Discord but off the top of my head; Longpath needs to be converted (Which we forked) and Cloud does not work.

EDIT: Oh wait he posted it above https://github.com/japanesemediamanager/ShokoServer/issues/52#issuecomment-296713565

[bigretromike]

are we transiting to ravendb or other database solution in near feature or we stick with what we go ?

[Cazzar]

At this point my intention is to get what's running now operating.

If you're able to jump on discord i can list what I have right now... Though most of its find what's broken as I go

On Wed., 26 Apr. 2017, 6:50 pm BigRetroMike, notifications@github.com wrote:

are we transiting to ravendb or other database solution in near feature or we stick with what we go ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/japanesemediamanager/ShokoServer/issues/52#issuecomment-297300260, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8rpmRavhrluEqcXc0jRFY50dTSQ_jXks5rzwVagaJpZM4CYrXG .

[Cazzar]

@bigretromike

Currently known issues

• Sqlite
• anidb socket seems to sometimes be closed.

Though if you want to help, pull the latest Linux branch that should build and run fine.

[maxpiva]

Thanks for the great effort 👍 , we have to figure out how to map the OAuth authentication into the linux version, so cloud can work. Any suggestions?. We could copy the initial oauth configuration from a windows version initially to the linux version, at least you can test the cloud funcionality in that way... But probably a refactor is needed into cloudfilesystem to support OAUTH via WebUI. So user could add and authorize Cloud Folders.

[bigretromike]

@Cazzar did you try this solution for sqlite errors : https://stackoverflow.com/questions/6203597/trying-to-using-nhibernate-with-mono-sqlite-cant-find-system-data-sqlite#6203812 ?

I wanted to try them myself but currently there is something broken with models so I can't even compile it properly. Sadly I miss opportunity to build it 12days ago when it was for sure working.

Don't know what is the orgin of my problem, maybe vsc2015 dunno... maybe next time