speechles 2055 Posted October 10, 2020 Posted October 10, 2020 (edited) Close. That is the worker process "ffmpeg" creating those logs. We need the main process "EmbyServer" logs. https://support.emby.media/support/solutions/articles/44001159337-logs The EmbyServer logs. Those will give a better context of what else is happening and how long requests/responses are taking. We need to see the full EmbyServer log to see the timestamps. That will give an idea of what to do next. Stop Emby server then start it up again. To create new log file. Now recreate the problem on Roku. Go right to logs on your Emby server. Post that EmbyServer log. Edited October 10, 2020 by speechles
johnson.4204 0 Posted October 10, 2020 Author Posted October 10, 2020 OK I restarted the server and re-created the probleembyserver-63737945173.txtembyserver-63737884800.txtembyserver.txthardware_detection-63737945193.txtm. Here are all the logs that were created in the time frame that I was tinkering. Please let me know if this is what you are looking for, thanks.
johnson.4204 0 Posted October 11, 2020 Author Posted October 11, 2020 These are the only logs that appeared during that time period. I see a few were logged 5ish hours after the event, not sure if they help but here they are. ffmpeg-transcode-1eb62a5b-7cfc-4fec-bfcb-7e7fdf10edf5_1.txt ffmpeg-transcode-57558109-df94-46e3-9510-6cbdc2aac999_1.txt
Luke 42077 Posted October 30, 2020 Posted October 30, 2020 Hi, as a test, if you turn off hardware acceleration in server transcoding settings, does that help?
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now