Jump to content


Photo

Chromecast

chromecast arch_linux linux chrome

  • Please log in to reply
25 replies to this topic

#1 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 27 January 2020 - 10:24 AM

Hey, all -- I have just a few videos that won't consistently Chromecast. Messing with rate settings and such hasn't helped. I'm running ArchLinux with Emby Server 4.3.1.0 -- I've tried a bunch of different client devices, including an Android phone, Arch laptop, and Windows. The client doesn't seem to matter. 

 

What's fun is that it's specifically Chromecast with these files. They'll play back fine in the Android app and web player, and most of my files Chromecast just fine. 

 

I've attached the Emby log statements from one attempt, and here's the file metadata.

 

Attached Files



#2 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 27 January 2020 - 11:44 AM

Hi there, what happens when you try to play them?

#3 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 27 January 2020 - 12:32 PM

It will black the Chromecast screen and stay at 00:00 out of however long the video is. If I stop playing it, it goes back to the movie info screen exactly like normal. The app seems to be functioning normally in every way except that it doesn't hand off the stream for the video itself to the Chromecast player.



#4 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 28 January 2020 - 01:12 AM

@DarkFeather can you please attach the complete emby server log? Also it looks like this playback session had an ffmpeg log. can you please attach that too? Thanks.



#5 itkserver OFFLINE  

itkserver

    Member

  • Members
  • 21 posts

Posted 02 February 2020 - 12:13 PM

I've had this problem before, usually with anime.

Is it dual audio?

Have you tried casting with subs turned off?

For me, it was always some level of Xcoding error which chromecast doesn't handle well.

I've learned that a chromecast is not always enough. I'm slowly upgrading to Chromecast + Roku solutions. ;-)



#6 itkserver OFFLINE  

itkserver

    Member

  • Members
  • 21 posts

Posted 02 February 2020 - 12:18 PM

 

Hey, all -- I have just a few videos that won't consistently Chromecast. Messing with rate settings and such hasn't helped. I'm running ArchLinux with Emby Server 4.3.1.0 -- I've tried a bunch of different client devices, including an Android phone, Arch laptop, and Windows. The client doesn't seem to matter. 

 

What's fun is that it's specifically Chromecast with these files. They'll play back fine in the Android app and web player, and most of my files Chromecast just fine. 

 

I've attached the Emby log statements from one attempt, and here's the file metadata.

Weird, I had trouble with this movie as well on my ET-LGtv app. It worked fine with the subs turned off. I wonder if we managed to pick up the same copy ;-)
 


Edited by itkserver, 02 February 2020 - 12:19 PM.


#7 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 02 February 2020 - 12:37 PM

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue:
https://emby.media/c...port-a-problem/
Thanks !

#8 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 03 February 2020 - 07:57 PM

Hi there, let's look at an example. Please attach the information requested in how to report a media playback issue:
https://emby.media/c...port-a-problem/
Thanks !

 

Hey, @Luke -- I retested on the ArchLinux version below. I shutdown Emby, wiped the logs directory, retested casting that one movie, waited 60 seconds, and then shut down the Emby server. I'm attaching the logs that are created -- I don't see an ffmpeg logfile. Here's also the `ffmpeg -i` output on that file.

|> pacman -Qi emby-server
Name : emby-server
Version : 4.3.1.0-3
Description : Bring together your videos, music, photos, and live television
Architecture : any
URL : https://emby.media
Licenses : custom
Groups : None
Provides : None
Depends On : alsa-lib aom bzip2 dotnet-runtime-2.2 expat fontconfig fribidi glibc gmp gnutls lame libass.so=9-64
libdrm libfreetype.so=6-64 libjpeg-turbo libmfx libpng libtheora libva-drm.so=2-64 libva.so=2-64
libvorbisenc.so=2-64 libvorbis.so=0-64 libwebp libx264.so=159-64 opus skia-sharp sqlite zlib zvbi
Optional Deps : intel-media-sdk: Intel QuickSync support [installed]
Required By : None
Optional For : None
Conflicts With : None
Replaces : None
Installed Size : 80.33 MiB
Packager : Maxime Gauduin <alucryd@archlinux.org>
Build Date : Thu 23 Jan 2020 03:50:09 AM CST
Install Date : Mon 03 Feb 2020 03:29:14 PM CST
Install Reason : Explicitly installed
Install Script : No
Validated By : Signature

|> ffmpeg -i /srv/yggdrasil/Videos/Movies/Spy/Zero\ Dark\ Thirty.flv
ffmpeg version n4.2.2 Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9.2.0 (GCC)
configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libdav1d --enable-libdrm --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libjack --enable-libmfx --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxml2 --enable-libxvid --enable-nvdec --enable-nvenc --enable-omx --enable-shared --enable-version3
libavutil 56. 31.100 / 56. 31.100
libavcodec 58. 54.100 / 58. 54.100
libavformat 58. 29.100 / 58. 29.100
libavdevice 58. 8.100 / 58. 8.100
libavfilter 7. 57.100 / 7. 57.100
libswscale 5. 5.100 / 5. 5.100
libswresample 3. 5.100 / 3. 5.100
libpostproc 55. 5.100 / 55. 5.100
Input #0, flv, from '/srv/yggdrasil/Videos/Movies/Spy/Zero Dark Thirty.flv':
Metadata:
metadatacreator : Yet Another Metadata Injector for FLV - Version 1.9
hasKeyframes : true
hasVideo : true
hasAudio : true
hasMetadata : true
canSeekToEnd : true
datasize : 729010956
videosize : 588565352
audiosize : 137550880
lasttimestamp : 9417
lastkeyframetimestamp: 9417
lastkeyframelocation: 729064343
Duration: 02:36:57.34, start: 0.033000, bitrate: 619 kb/s
Stream #0:0: Video: h264 (High), yuv420p(progressive), 720x384 [SAR 1:1 DAR 15:8], 497 kb/s, 29.97 fps, 29.97 tbr, 1k tbn, 59.94 tbc
Stream #0:1: Audio: aac (LC), 48000 Hz, stereo, fltp, 112 kb/s
At least one output file must be specified

Attached Files



#9 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 03 February 2020 - 09:42 PM

Try using the web app by ip address instead of computer name.

#10 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 04 February 2020 - 05:09 AM

Try using the web app by ip address instead of computer name.

 

Going by IP does not seem to improve behavior. Some testing I did does indicate that it seems to be the FLV format that's causing the issues, and it's more systemic than I thought. Chromecast playback still doesn't work, but I've also seen web playback of this file crash the network sockets tied to the Emby application. Log attached. It seems that web playback works for about twenty minutes and then the app drops its network sockets on the floor and doesn't recover. I'm not sure this isn't plaguing some other files and formats -- this one seems to be the good canary to use for now.

 

Playback in VLC over sshfs of the same file seems to work exactly as intended.

Attached Files


Edited by DarkFeather, 04 February 2020 - 05:12 AM.


#11 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 04 February 2020 - 12:43 PM

So you're able to play other files?

#12 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 04 February 2020 - 05:08 PM

@Luke not for longer than about 20 minutes. After that, the server gives up.



#13 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 04 February 2020 - 05:18 PM

Are you sure you supplied the right log file? It doesn't contain any activity from Chromecast.



#14 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 04 February 2020 - 06:12 PM

Are you sure you supplied the right log file? It doesn't contain any activity from Chromecast.

 

I'm not really seeing a lot of log activity from the attempt myself. Here's all my log activity since I wiped the folder. 

Attached Files



#15 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 09 February 2020 - 12:31 AM

Are you sure your chromecast receiver can even reach your emby server? Is this inside your local network? 



#16 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 09 February 2020 - 07:15 PM

Yes, I'm sure. They're all inside the local 10.0.1.0/24 subnet, and I can cast from the server using VNC and a browser.



#17 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 09 February 2020 - 10:36 PM

Is the local lan address displayed on your server dashboard correct?



#18 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 10 February 2020 - 04:53 PM

It is, though at some point I'm wanting to lock Emby into only allowing access through the remote endpoint. The stream should then be negotiated between the phone and the Chromecast which will be on the same LAN subnet. I'm thinking that to accomplish that I set 127.0.0.1/32 as the LAN networks and 127.0.0.1 as the local network binding. I'm then fronting Emby with a subdomain virtual host in my webserver along with all of the other apps in my ecosystem. 

 

I'm thinking this will fix problems where the server's local IP reverse lookup doesn't match the hostnames on the certificate -- if it always goes through the external endpoint, then hostname validation will work. 



#19 Luke OFFLINE  

Luke

    System Architect

  • Administrators
  • 156973 posts
  • Local time: 07:49 PM

Posted 10 February 2020 - 06:53 PM

 

 

 if it always goes through the external endpoint, then hostname validation will work. 

Right but we don't currently have any way of allowing you to configure that for just chromecast.

 

 

 

The stream should then be negotiated between the phone and the Chromecast

 

That's actually not how it works. The phone just tells the chromecast receiver to play something from your emby server. The stream then happens between the chromecast receiver and your server. That's why your Chromecast needs to be able to reach your emby server.

 

Does this make sense now?



#20 DarkFeather OFFLINE  

DarkFeather

    Advanced Member

  • Members
  • 38 posts
  • Local time: 05:49 PM

Posted 10 February 2020 - 07:14 PM

That does make sense, and I'm not looking for this to happen only for Chromecast -- in fact, my goal is to have all my Emby traffic (inside or outside my subnet) go through the external endpoint. I'm hoping to get my Emby installation to cast in much the same way as YouTube or Netflix, coming through the frontend of my domain on subdomain.example.com:443 rather than 10.0.1.3:8096 or something of the sort.

My biggest reason for wanting this is to reduce exposure of my SSL private key to only those services that need it and preferably in a semiautomatable format for certbot. The pfx requirement in Emby makes that more complicated from a security standpoint. 







Also tagged with one or more of these keywords: chromecast, arch_linux, linux, chrome

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users