Search the Community
Showing results for tags 'shield pro 2019'.
-
Has anyone else experienced playback issues with the TrueMAX editions of Harry Potter 1-4 and Fantastic Beasts trilogy by Klexos (icebox616)? I understand they are large files by most definitions, but when using an external player such as VLC, Nova Player, or JustPlayer, they stream fine, no hitches, DTS HD MA passthrough works as expected, HDR10 also works as expected, but when using the internal player, DTS HD MA passthrough works as expected, but HDR does not seem to engage and there is constant hitching in video ONLY. Additionally, the renderer listed under stats for nerds is FFMPEG versus the usual MediaCodec of other files. All files are being reported as Direct Plays. Any ideas would be greatly appreciated. Setup Server: Unraid server with Emby 4.8.10.0 wired to Orbi Files: https://pastebin.com/i28CfKJP Client: Nvidia Shield Pro 2019, Sony X90K, Yamaha RX-A2060, wired to Orbi Network: Netgear Orbi RBR50 (500 down, 25 up as tested from the client) P.S. Boy would it be nice if there was a quick way to watch with an external player, something in the long hold or triple dot menu would be nice. Having to go in and out of the playback settings is quite a pain.
- 11 replies
-
Emby AndroidTV 1.8.28g Stops Working on 2019 Shield Pro
Netfool posted a topic in Android TV / Fire TV
Emby's AndroidTV app version 1.8.28g fails to play some files. The first frame of the file is flashed on the screen, the buffering ring reappears and then the "too many errors" message appears. These files play normally on Emby Web 4.5.2.0. Once the AndroidTV app gets into this state, nothing will play until the app is restarted. (In the latest case by "sleeping" the shield and re-selecting the Emby app.) After re-entering the Emby app on the Shield the files played normally. To me this smells like a memory leak. Relevant log files from the server attached. An AndroidTV log was sent: User RAM at 11:02 AM Pacific (14:02 Eastern). Screenshot of the Dashboard Logs page included to establish the timeline for the various ffmpeg-directstream logs. Wouldn't it be more useful to have the ending (or starting) timestamp as part of the log name rather than 40 characters of apparently random hex? embyserver.txt ffmpeg-directstream-1a091431-a63c-4ffc-af36-330cfc5d2520_1.txt ffmpeg-directstream-8cda74c2-b9e0-417d-9f09-68ed7b4bf168_1.txt ffmpeg-directstream-32c95d1e-a713-47a8-8dec-42c83cbf92e7_1.txt ffmpeg-directstream-496e315f-1d63-464e-8d87-9a3011dd8959_1.txt ffmpeg-directstream-42493a61-d92a-45a0-a82a-fb239994674f_1.txt ffmpeg-directstream-db806afa-645d-4edb-b18b-9668e7144de0_1.txt ffmpeg-transcode-0ebe4dbb-0387-4622-9677-65169fc13462_1.txt ffmpeg-transcode-88aef408-144d-4a89-8b6e-8c15c868293e_1.txt ffmpeg-transcode-650b7b8a-05fb-4d1e-85b4-0ff8baa0d658_1.txt -
Server version 4.5.2.0. stopped suddenly watching a recording from an HDHR Extend with transcoding turned on. Server log and the ffmpeg-directstream log attached. Client logs sent at 8:56 PM Eastern time. User RAM, program KOIN 6 News at 5. Both server and client were running on the same Shield Pro. embyserver-63739330546.txt ffmpeg-directstream-0ffc092e-ecf2-4391-a49b-e1b1a8b4abe3_1.txt