Weird new issue

[Nusse 0]

So up until recently I have had no issues with Emby running on my *nix server but suddenly I can't cast to Chromecast from the linux box and I think somehow permissions got jacked up on the nix box.

 

First my setup:

 

Ubuntu Server (I've tried Debian and LInux mint with same result)

Videos stored on a Synology NAS (Share is mapped via fstab to local mount points)

 

The problem:

 

When I cast on my phone (android) to a chromecast using the emby app, it starts to play for a second... then drops back to a "Ready to Cast" screen. 

 

If I play the video on my phone without casting, it plays just fine

 

I can cast other things to the chromecasts without problems

 

 

What else I have done to test:

 

I stood up a windows box just to make sure it wasn't something else, and that works without issue.  If I try the same video off of the *nix server, I get the above mentioned error.

 

 

My suspicion is it's permission related on the *nix server but I've gone and reset everything just to make sure (setting things to 777) and still the same problem.

 

Now I know I need to upload logs to help, but I can't at the moment and will add later.  I was just hoping someone ran in to this before and knows a fix.

 

Thanks.

[Luke 37213]

It's probably network related. It sounds like your casting device can reach your Chromecast, but your Chromecast cannot reach your emby server.

[Nusse 0]

It's probably network related. It sounds like your casting device can reach your Chromecast, but your Chromecast cannot reach your emby server.

I considered that as well, but the windows server I stood up that works fine, is on the same network.  They are literally wired next to one another and the NAS.

[Nusse 0]

I considered that as well, but the windows server I stood up that works fine, is on the same network.  They are literally wired next to one another and the NAS.

Alright so....... more oddness but I've narrowed it down to it being Linux/Emby somehow.

 

New troubleshooting steps:

 

On a whim I tried casting to my Chromecast Ultra...... AND IT WORKED.

Then I tried casting the same video to a non-ultra....... and it did the error above.

I then tried casting the same video from the Windows Server to the non-Ultra and it too worked.

 

So by sheer process of elimination I've narrowed it down to something on Emby/Linux when casting.  It isn't permissions since I can get it to cast to the Ultra without issue and it isn't network related since I can cast from the Windows Server without issue.

 

And here is the other rub...... when I stood up the Windows Server, I restored the settings from my Linux box (minus the library definition) so the playback settings and user info would be the same.

 

And what is also odd, is that I have tried it on no less than 4 different *nix versions and get the same thing.

 

I know I still need to upload log files to help, but this just keeps getting weirder ... and weirder.

Edited March 16, 2018 by Nusse

[Luke 37213]

Ok, yes if you can attach your server log then I'll review that. Thanks.

[Nusse 0]

This isn't the full log (I'm not at the server and remoting in from where I am at is...... a challenge. But I think I found the issue:

 

2018-03-18 09:05:15.895 Error HttpServer: Error in HttpListenerResponseWrapper: Broken pipe

*** Error Report ***
    Version: 3.2.40.0
    Command line: /opt/emby-server/system/EmbyServer.dll -programdata /var/lib/emby -ffmpeg /opt/emby-server/bin/ffmpeg -ffprobe /opt/emby-server/bin/ffprobe -updatepackage emby-server-deb_{version}_amd64.deb
    Operating system: Unix 4.13.0.37
    64-Bit OS: True
    64-Bit Process: True
    User Interactive: True
    Processor count: 8
    Program data path: /var/lib/emby
    Application directory: /opt/emby-server/system
    System.InvalidOperationException: EndReceiveFrom can only be called once for each asynchronous operation.
     at System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
     at Emby.Server.Implementations.Net.UdpSocket.EndReceive(IAsyncResult result)
     at Emby.Server.Implementations.Udp.UdpServer.OnReceiveResult(IAsyncResult result)
    System.InvalidOperationException
     at System.Net.Sockets.Socket.EndReceiveFrom(IAsyncResult asyncResult, EndPoint& endPoint)
     at Emby.Server.Implementations.Net.UdpSocket.EndReceive(IAsyncResult result)
     at Emby.Server.Implementations.Udp.UdpServer.OnReceiveResult(IAsyncResult result)

 

This would explain why an Ultra is working and the "regular" ones aren't ... and why it works on the Windows Server.  Looks like ffmpeg (or Emby's use of it) is a bit borked.

Edited March 18, 2018 by Nusse

[Nusse 0]

So I think we can close this thread as I fixed my issue.

 

Here is what I had to do:

 

1. Completely remove and purge emby (for ubuntu the command was: sudo apt-get remove --purge emby-server)

2. Delete the remaining bits (mount points, services, etc)

3. Rebooted (it's *nix so really shouldn't of needed to do this)

4. Created new mount points and double-checked fstab

5. Reinstalled

6. set permissions on mount points

7. Set up Emby using the wizard.

8. Recreated each user by scratch (I think this was the key... before I had been restoring everything, but this time I did all by hand)

9. Tested and it now works.

10. Danced in the streets.

 

I don't know whether it was the fresh install without a restore or whether the users were corrupted or what. .. but after all of that I've successfully been able to get farther than I had been (usually errors out in a second or two).  My assumption is that it was a combination of all the above and all my troubleshooting ended up compounding the problem.  So a fresh start did the trick.

 

Hopefully it holds.

[Luke 37213]

Thanks for the info. Curious, for your new install did you follow the latest instructions on our website?

[Nusse 0]

Thanks for the info. Curious, for your new install did you follow the latest instructions on our website?

No I didn't.  All I did was a wget of the deb file, dpkg install .. made "emby" the owner of the mount then set it to 777.

[Luke 37213]

Ok that's just fine, thanks. I wanted to make sure you didn't use the older OBS package.

[Nusse 0]

Ok that's just fine, thanks. I wanted to make sure you didn't use the older OBS package.

I'm wondering if that wasn't part of the problem.  I looked at the install process I was using before (a script) and it appears to have pulled an older version... but I am not positive at this point.   Since it was working then suddenly wasn't,  I am not sure that was the cause. But... it's working now and that is all that matters.

[Luke 37213]

Glad it's working. Thanks.

[Nusse 0]

One new thing I would add, is that while everything "works" metadata doesn't download. But, I found that issue as well........ sorta.......... I have to refresh the permissions on the mount point after boot/re-mounting for some reason.  I suspect it's something I have set up as my fstab line is pretty generic and it only seems to be impacting metadata (I get access denied messages in the emby logs... so pretty clear indicator ).

 

Worse case I'll write a script that runs every hour or something that resets the permissions and be done with it...... it's a setting somewhere I am just too lazy right now to do much more

[mastrmind11 717]

One new thing I would add, is that while everything "works" metadata doesn't download. But, I found that issue as well........ sorta.......... I have to refresh the permissions on the mount point after boot/re-mounting for some reason.  I suspect it's something I have set up as my fstab line is pretty generic and it only seems to be impacting metadata (I get access denied messages in the emby logs... so pretty clear indicator ).

 

Worse case I'll write a script that runs every hour or something that resets the permissions and be done with it...... it's a setting somewhere I am just too lazy right now to do much more

If you don't feel like getting to the actual cause of the permission problem, and assuming your parent folder(s) have the proper permissions, easiest way to do what you want w/o having to mess w/ cron is to play w/ the setgid so every file created inherits from the parent:

chmod g+s /path/to/parent

[Nusse 0]

 

If you don't feel like getting to the actual cause of the permission problem, and assuming your parent folder(s) have the proper permissions, easiest way to do what you want w/o having to mess w/ cron is to play w/ the setgid so every file created inherits from the parent:

chmod g+s /path/to/parent

Thanks for the tip I had forgotten that option.