Search the Community

Running The Nvidia Shield Emby Server 4.5.1.0 on a 2019 Nvidia Shield Pro. Attempting to use the Nvidia GPU to do hardware trans-codes has never worked for me. Ever hopeful, I wanted to test under 4.5.1.0 and discovered a completely different problem. I attempted to transode a file from H264 to HVEC. That first conversion failed as before. I also tried to convert the file to a 4MB/sec version. Hardware trans-coding of that failed as well. I did the same for 3 additional files to test whether or not it was a problem with that specific file. All failed to used the hardware encoder. However, when I went back and examined the logs, in all cases Emby attempted to convert the first file, NOT the file I asked it to convert. Conversions were started from the Movie page in some cases and from the library thumbnail for the movie in others. A screenshot of the Logs page and relevant logs are attached. (The screenhot to establish the order of the transcode logs). The Remux log came from playing the last movie to confirm its was not originally shot in 16 by 9 (it was however released letter-boxed) and mostly in monochrome. It's possible that the initial problem was caused by cancelling the first conversion from the dashboard. Allowing it to complete software a software trans-code in all cases would have tens of hours. embyserver.txt ffmpeg-remux-3b027453-a1da-4a8a-811f-c14d291c3ebe_1.txt ffmpeg-transcode-3cb5e847-7345-4bb5-b335-9a1e7e88e3c6_1.txt ffmpeg-transcode-8db60443-f8f7-4cc2-851e-aa53df25e619_1.txt ffmpeg-transcode-bd201aa7-eece-4a32-ae0c-3fe8ae75076a_1.txt ffmpeg-transcode-cc0c53cb-384f-47a0-92d2-8172e76f6c30_1.txt ffmpeg-transcode-d13fff65-36f7-48c7-b57a-9e29c7b38769_1.txt ffmpeg-transcode-d715900d-b7ae-4f42-8d84-a4a8d04c4ca2_1.txt ffmpeg-transcode-da1997bb-81b1-412e-ab21-10b73c21c3a5_1.txt

Ever since I updated to 4.5.3.0, when my kids switch from one stream to another before it finishes, the dashboard tile representing their connection will begin flashing back and forth between the new stream and the cancelled one. This would only be an aesthetic problem, except it is clearly breaking playback reporting. Hundreds of zero-duration streams (at least 1 every minute until the client browser is reset) are added to the logs, and the duration of real streams is not being properly summed. I've noiced that if I am fast enough, I can hit the stop button on problem stream from the dashboard as it strobes back and forth. These appears to fix it, but can hardly be considered a solution. I'm on ubuntu server 20.1 anybody else having this issue?