Jump to content

Emby isn't closing used network ports.


anderbytes

Recommended Posts

anderbytes

While the project is in open source, I truly believe it's in the right path, and devs are doing what they can, priorizing the issues that impact the most number of users.

 

As server issues will always have a higher priority, we have to keep remembering them to also look to Android...IOS...etc...

Link to comment
Share on other sites

runtimesandbox

Dust in the wind..... all we are is dust in the wind........

 

Inevitably this is what happens when a free product becomes a paid product.  There are not enough paid developers to keep up with demand, but to hire more developers mean the paid developers take in less cash.  This in turn then means that volunteer's are less likely to help for free, when they see the other guys making a ton of money off of it.

 

I see this as the future of Emby.  Power and greed corrupts, software development is no different than politics =)

 

I don't see this being the case. Emby isn't exactly not free. Having extra features that require you to pay to support the developers I don't think is a bad idea at all. Whilst the amount of time the devs put in to this is project is huge, they are still working for free and they will still have bills to be paid. 

 

Whilst this bug has been causing issues for a while for a few of us users, I'm confident they will get round to fixing it in due time. 

 

If you can help narrow it down (it might not actually be caused by android) then great. Please help keep this post on topic

Link to comment
Share on other sites

I added a 5 minute timeout to http connections with the last stable release. if there's still an issue then it's probably something else.

  • Like 2
Link to comment
Share on other sites

anderbytes

1. Latest Server or latest Android?

2. Does this timeout also applies to https?

3. This timeout didn't exist at all before, right?

Edited by anderbytes
Link to comment
Share on other sites

MSattler

 Whilst the amount of time the devs put in to this is project is huge, they are still working for free and they will still have bills to be paid. 

 

Working for free?  There are just two paid developers, as far as I know no one else is getting paid.  What developers aside from Luke and Erik are still contributing on a regularly basis?  You apparently are not looking at Github very often.  And I think you also missed the big article awhile back that states that Luke is working Emby full time, so he is not working for free but being paid out of the Emby proceeds.  Would you categorize that as working for free?  If so... then I guess I am working for free too =)

 

This isn't a dig at anyone, but if we are gonna have the discussion let's just get the story straight.  

 

*EDIT*  Let me clear one thing up in regard to my stance on all of this.  I have no care in the world if Erik and Luke make money off of Emby.  The issue for me is that if we have paid developers, it limits the number of volunteer resources we are going to see.  Look around at the active apps by volunteer developers, and which of these are still being supported on a daily/weekly schedule?  The only one I see is  Roku.

 

Erik and Luke are developing the following all at the same time:

 

Android App

Fire TV App

Emby Chromecast

Emby IOS

Emby Theather

Emby Server

Samsung Tizen App

Some Emby Plugins

 

Now that is a lot of required development time, and with just two developers working on all of these products, release cycles, bug fixes are never going to be at the speed the userbase wants.  What developers would want to develop for a product suit that they cannot charge for, and where volunteer developers are not being paid.

 

Again, not a poke at anyone, but this is something to keep in mind if staying on/switching to this platform.

Edited by MSattler
Link to comment
Share on other sites

@@MSattler

 

You make a good point. It is difficult to code for emby because of the lack of documentation on the API and its various endpoints. Usually a volunteer has to spend time fiddling through other apps source code such as the emby web client to see how it is done. Once you see how their apps code does it you can start to feel around what is required and port that method to your app. Other times there is no existing documentation on some endpoints. For these you just have to start throwing queries around until you see how it works.

 

To write the required documentation that would encourage volunteer developers requires a developer. They are the only ones with direct knowledge of the API since they wrote it. This is a double edged sword. To code or write documentation? Both add value, but one has higher priority. Documentation is low on the priority scale. If they build the documentation better with more endpoints and how they should be used and make it like twitter has done for their developers you can get more volunteer community apps appearing. Twitter built their ecosystem from volunteer third party apps. The same can eventually happen here if they make it possible.

 

It is discouraging to try to make cool things with emby just to find the documentation so lacking. To use the web client source code is so painful to use as documentation for various API endpoints. I am sure there are many others who wish to contribute but fall into this same trap. Emby is painful to code apps for. It doesnt have to be but presently it is. Other developers feel free to chime in on this.

 

So in the end, you get what you give. There needs to be twitter like documentation for the emby api.

 

https://dev.twitter.com/rest/public

 

See how their API embraces third party developers with so much information rich with detail. This is what emby requires. Only after doing something like this will you see community members contributing code, new apps, and so much more.

 

https://www.youtube.com/watch?v=FnfXoVCUAS4

 

...with a little help from my friends. Instead of seeing users as dollar signs, see them as future developers of the emby brand. See them as future code fix contributers. You can see them as more than their monetary value.

 

 

Note: I am aware this is off-topic to the original poster, but since it went there, here we are.

Edited by speechles
  • Like 2
Link to comment
Share on other sites

anderbytes

@@speechles is correct. This is a specific topic for a problem that torments some users ...

 

If anyone wishes to continue this discussion, better take it to the correct sub-forum.

Thanks

Link to comment
Share on other sites

  • 3 weeks later...
anderbytes

I'm experiencing the issue to this day...

 

I probably will be forced to create a reverse proxy to intermediate the connections to Emby, and hope that Nginx will close all as needed.

Link to comment
Share on other sites

  • 2 weeks later...
anderbytes

After new 5930 server... I'm having trouble reproducing the issue!!

 

Hopefully the problem wil be gone forever.

Will keep this updated for a while, reporting my tries.

  • Like 1
Link to comment
Share on other sites

runtimesandbox

I also have not experienced this in a while. Not had to restart the server in the last few weeks

Link to comment
Share on other sites

anderbytes

Today the problem was back.  :-((

 

Don't know exactly what made the problem come back.... other than some errors that appeared in the logs.

 

Guess I'll have to continue the tests when the errors are gone.

I'll be posting the errors soon in a new thread.

Link to comment
Share on other sites

anderbytes

Guys...unfortunately... the problem still exists.

 

Couldn't see it for some time... but somehow it's back.  :-/

 

It's really frustrating.

I'm almost giving up hope and creating a recurring script that restarts Emby if several connections are opened but no file from library is being used by Emby process.

Link to comment
Share on other sites

Happy2Play

Are you running Server 2012 for this (not 2012 R2 but just 2012)?

Most if not all that have reported here are on non-Windows systems.

Link to comment
Share on other sites

gstuartj

I had to restart my Emby VM because of this issue yesterday on Debian 8. Eventually my network speeds slowed to a crawl on all clients. For now I've set up a cron job to restart the service each day when there are no clients, but it's definitely not an ideal workaround.

Link to comment
Share on other sites

anderbytes

Not even close of an ideal workaround.

 

As the code works OK in Windows and NOT OK in Linux.... all I can think is that Mono (or interface Mono-Linux OS) is the culprit.

 

Can the devs find some specialized help with this matter? It may be something that other software (that uses Mono) had dealt with in the past.

 

 

 

ps: don't understand why... but the last time I had to restart Emby... the ports took some minutes to go away, they weren't immediately closed, as they used to. Strange...

Edited by anderbytes
Link to comment
Share on other sites

gstuartj

Mono would be my first bet as well. What version of Mono are you running? (mono --version)

Link to comment
Share on other sites

anderbytes

Latest stable. 4.3.2.4 , if I'm not mistaken.

Link to comment
Share on other sites

dcook

I have windows version running for over 6 months, server has not been rebooted in over 90 days and I don't have any issue with ports

 

Version 3.0.5931.0

Edited by dcook
Link to comment
Share on other sites

anderbytes

I have windows version running for over 6 months, server has not been rebooted in over 90 days and I don't have any issue with ports

 

Version 3.0.5931.0

 

Exclusive Linux issue.... It is known.  ;-)

Link to comment
Share on other sites

runtimesandbox

I agree it would indicate an issue with mono

 

Interestingly when I run mono version I get the following

 

 


Mono JIT compiler version 4.2.1 (Stable 4.2.1.102/6dd2d0d Thu Dec  3 03:58:58 UTC 2015)
Copyright © 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com
        TLS:           __thread
        SIGSEGV:       altstack
        Notifications: epoll
        Architecture:  amd64
        Disabled:      none
        Misc:          softdebug
        LLVM:          supported, not enabled.
        GC:            sgen
 
This is running on Debain 8.4 in a VM with kernel
 

4.4.0-0.bpo.1-rt-amd64 #1 SMP PREEMPT RT Debian 4.4.6-1~bpo8+   1 (2016-03-20) x86_64 GNU/Linux

 

Edited by spudy12
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...