Jump to content

Playback Failed - Loading and Then Stops (Same Stable & Beta Server)


bungee91

Recommended Posts

bungee91

There seems to be something unique about this file (and some others that I have) that is causing playback issues on the Roku client. I am not seeing this issue locally on the web client or ATV clients so I do not believe the file itself is the culprit.

I had the same report/condition on the most recent beta server with the same file, and now with the stable server where the logs are from that are attached. On the beta server as a test I had disabled HWA just to ensure that was not the case, and it made no difference. I expect the same on the stable server but did not test that specifically (my beta server uses Intel HWA, my stable uses NVIDIA HWA). This created a lot of FFMPEG logs, so I will attach all of them even though I assume multiples are very similar to one another. Any help on this or if it could be a setting or something on my end that needs to be tweaked (I noticed a tone mapping and subtitle warning in one of the logs) let me know and I will test. Thanks

ffmpeg-transcode-100428f7-a961-48d9-a6c5-420c91f9dea7_1.txt ffmpeg-transcode-cb54b0ef-4168-4d53-8394-9f692ae76a8d_1.txt ffmpeg-transcode-39cf4a82-5f53-4773-a39b-7b20a5890e7d_1.txt ffmpeg-transcode-07262294-0116-4fd0-ba56-6af443ce45e5_1.txt ffmpeg-transcode-baf8efef-7092-4d16-8edd-797d1664ce74_1.txt ffmpeg-transcode-fe13dcea-de9d-4413-be61-3045f0d96cde_1.txt ffmpeg-transcode-b38e38da-2504-45b6-9f90-db21fe2b4a0c_1.txt ffmpeg-transcode-077216df-8785-47f4-ad51-c2b2df0c12a2_1.txt ffmpeg-transcode-ee7c7c1a-8fa6-4c12-819e-beab08d3bd69_1.txt ffmpeg-transcode-495acfdf-4bfa-46b5-9239-30df1d746d70_1.txt ffmpeg-transcode-4497c0da-4e95-4aa3-bf70-07832ca4172b_1.txt ffmpeg-transcode-d6e52953-0357-4fea-9822-1c695852b6ea_1.txt ffmpeg-transcode-8baa0709-64ec-4128-afef-0cb8ed4958e5_1.txt ffmpeg-transcode-69cd7d46-798e-45ae-9099-f246c68d62ee_1.txt ffmpeg-transcode-b5df6cf5-3ebf-4d03-869c-45d67ae52469_1.txt ffmpeg-transcode-4bde7370-d71d-4e20-b4b9-0ccccdb6e072_1.txt ffmpeg-transcode-4acbff96-5978-42ca-baa3-42cf0c70f61b_1.txt ffmpeg-transcode-94ebe811-c28c-4413-b0f6-fd1d11872a4c_1.txt ffmpeg-transcode-3c11bbb6-5354-46ca-a352-4404ce0a1c49_1.txt ffmpeg-transcode-cf99da84-1365-4841-acb3-78b36d2a00e1_1.txt ffmpeg-transcode-1111a009-2933-41fa-8091-e05f628bf353_1.txt ffmpeg-transcode-6cf6ca09-b184-4391-9701-486ff7536fa8_1.txt ffmpeg-transcode-f45b8ba6-454c-44d1-ac9d-72a7d9fb585e_1.txt ffmpeg-transcode-3911a0ac-4f4c-426d-91df-0fa0c3e51d65_1.txt ffmpeg-transcode-108e31e2-b67c-4b3b-98dc-b4b3368212ee_1.txt ffmpeg-transcode-ca42ba89-bf63-4aa3-9ce6-ef8a262ddeed_1.txt ffmpeg-transcode-5771d631-6ceb-49c2-932c-c5318ba7a5c0_1.txt ffmpeg-transcode-7fe5efac-ee0e-4caa-83aa-e5456ebcfb0d_1.txt ffmpeg-transcode-4b2dfae2-76fd-450b-bba8-4c4663b4cefc_1.txt ffmpeg-transcode-ec00edc6-109c-475d-aef3-80fed40ab188_1.txt ffmpeg-transcode-d6cf75b1-df84-432e-ac1e-ae527d539f2a_1.txt embyserver.txt

Link to comment
Share on other sites

Apologies. It looks like the file is DolbyVision with HDR. What model number of Roku is this?

The reason I ask is because we need to update our device profile detection within Emby for Roku to better detect the new DV flags the server allows. This is presently in Alpha test along with some other things. But there will be an update to bring the device better inline with the ability to Direct Play the HDR layer of the DV material for example.

In your logs it also shows Direct Play error like it has already tried to direct play it. We may need the actual file. No need to provide it since we know where we can get it. For scientific purposes to fix this issue this is the only way. I will be able to determine what is wrong once I can see this for myself. I have several Roku models. This is why I am ask you for the model number. In case I do not have that exact model we might need to obtain one.

I can give you more information once I can run tests after I have the full file. Curious why it fails to play as I have similarly constructed titles and they play without issue. But I am using the new device profile detection capabilities in the app we have built. That might be the difference.

Also thanks for the tons of playback attempts. It shows there is definitely an issue as it is repeatable over and over. I can know more tomorrow. I have slow internets.

Edited by speechles
Link to comment
Share on other sites

Also.. try putting the file inside an MP4 instead of an MKV and see if that makes it Direct Play possible. Some Roku models are very strict about DV being inside MP4 only.

 

Edited by speechles
Link to comment
Share on other sites

bungee91

Thank you for the prompt and detailed response! A couple of thoughts on this. I am uncertain the model off hand other than what is in the log that stated Roku Express (which I assume is not at all helpful) and I thought there was a number along with it. If this is something I can instruct my mother to provide from the app, or looking at the device, I would be happy to.

Now the direct play side of this, lets talk about that as it could be a separate issue. This user/profile is globally set to a 3mbps limit, and I had her locally (just in case it was ignoring it) try to set it to say 5mbps and had the same condition. I am certain based on her and my internet direct play would not be possible (let alone it needs to downmix likely to two-channel audio/etc.).

So for my follow-up actions here. If you can let me know the easiest way to gather the model # (if in the app it would list it, that would be great) I will get that quickly.

Link to comment
Share on other sites

bungee91
3 minutes ago, speechles said:

Also.. try putting the file inside an MP4 instead of an MKV and see if that makes it Direct Play possible. Some Roku models are very strict about DV being inside MP4 only.

Yeah I assume that may resolve it, I just don't typically want to convert the file if not needed for myself...LOL. Since it is my Mom I also don't expect her to request it in the app and then play it from the newly created file. Many of the files I get now a days will be similar to this one, however if it will take time to resolve I completely get it and appreciate the efforts.

Link to comment
Share on other sites

dev.thumb.jpg.9b12e2a35462744321bd03d24e309d79.jpg

ffmpeg-remux-4f7f6c10-4ad7-461a-8f38-aaebdca69b53_1.txt

On my Roku 4K express I can get this to play the HDR layer of the DV material with the new device profile capabilities. It will direct play if I leave this on highest quality. The audio is converted but the video stream is direct played and copied. Because I have the "Volume Mode" set on the Roku it will convert to Stereo so the Roku can do "Leveling" or "Night" mode.

 

dev-1.thumb.jpg.905a093bd8df09e69889d5ffd01ba790.jpg

 

ffmpeg-transcode-100428f7-a961-48d9-a6c5-420c91f9dea7_1(3).txt

When I change it to quality limit of 1080P and 5Mbit per second it starts to transcode I get the same issue. Opened the OSD on both to show it is the same file. The direct played copy on top is direct playing showing on the Roku TV with the Roku express 4K hooked up. Notice it is playing though and falls back to software encoding. I get it to play and it looks like HLS is used. But is this accurate? I know the stats for nerds isn't.

@softworkzIs this a known problem presently?

Edited by speechles
  • Like 1
Link to comment
Share on other sites

I think I see what is happening.

 

Spoiler

10:24:45.286   Stream #0:1(eng): Audio: aac (LC), 48000 Hz, stereo, fltp, 192 kb/s (default)
10:24:45.286     Metadata:
10:24:45.286       encoder         : Lavc59.21.100 aac
10:24:45.287 elapsed=00:00:00.24 frame=    1 fps=0.0 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A throttle=off speed=   0x    
10:24:45.288 elapsed=00:00:06.07 frame=    2 fps=0.3 q=0.0 size=N/A time=00:00:00.00 bitrate=N/A throttle=off speed=   0x    
>> ThrottleBySegmentRequest: RequestPosition: 00:00:00 - TranscodingPosition: 00:00:00 - ThrottleBuffer: 0s (Treshold: 120s)
10:24:45.389

[q] command received. Exiting.

10:24:45.392 10:24:45.393 [segment @ 0x736740] Opening '/config/transcoding-temp/BA807E/BA807E.m3u8.tmp' for writing
10:24:45.393 SegmentComplete=video:0 Index=0 Start=0.000000 End=1.666667 Duration=1.666667 offset_pts=0 start_pts=0 Frames=40 filename=BA807E_0.ts
10:24:45.393 elapsed=00:00:06.17 frame=   40 fps=6.5 q=8.0 Lsize=N/A time=00:00:01.45 bitrate=N/A throttle=off speed=0.235x    
10:24:45.393 video:1kB audio:41kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown
    Last message repeated 1 times
10:24:45.408 EXIT
10:24:45.424 [aac @ 0x758f00] Qavg: 36377.379
10:24:45.424

 

The FPS on your transcoding is far too low to do this in real time. That Roku will get stuck in buffering hell. Your logs show the transcoder will attempt to transcode anywhere between 0.3 to 6.5 FPS depending on what else is going on with your servers CPU. This process is very CPU intensive. Especially with tone mapping applied. That 0.3 - 6.5 FPS is not enough for her to watch in real time. It will just stay buffering aka endless buffering hell.

I missed this the first time. Because the Roku cannot Direct play above the bitrate of the video stream it cannot copy the video stream. Once it has to convert it the game is over. It cannot do this anywhere near real time.

When I transcode this same item it punishes my CPU to transcode too. But my CPU is beefy enough that it can stay anywhere between 30 - 58FPS while doing so. So I can do this in real time.. but just barely. You need it to always remain above 30FPS for this particular conversion to never buffer on the Roku.

What kind of CPU is your Emby server running on? I ask because this type of conversion will fail on hardware and will need to fallback to software and at that point your CPU is going to be punished.

It may be worth it to you to also procure a 720P copy of this same title. Then put it in the same folder as the other copy you have. Emby will then provide a "Versions" drop down where she can select which will best play for her. It should auto select the 720P for her since her Roku will show it can direct play.

Edited by speechles
Link to comment
Share on other sites

bungee91

Appreciate it, and quick reply here from my phone. I just updated my server and I don't think my CPU (i7-14900k) would find this very taxing overall. Maybe something's not right, however my Emby Docker on UnRAID has full access to all resources.

Link to comment
Share on other sites

bungee91

Following up here with a bit more information and testing/logs. Again want to say thank you @speechlesfor the support and level of testing you are doing to help.

I will admit that I am still uncertain about the discussion of direct play for my situation on the Roku client when the bitrate setting compared to the source file is required to be a full transcode. Maybe that is nothing, uncertain.

I did a test this morning on a local 2-channel setup (HDMI to Tv) Shield with ATV app on the same file. I also set the streaming quality globally on the app to 3mbit for playback. Logs attached. The first kept HWA enabled, and the 2nd I completely disabled it on the server. I witnessed ~40% CPU load during this time, and playback was flawless (minus it being 3mbit; yuck!).

I also mistyped my CPU above, which is an actual model (ha!) of an i7-14700k. With a CPU mark of 53516 it is no slouch. I do agree this operation is taxing and certainly not ideal, the server should be able to handle it just fine.

Let me know what else if anything I can do to test, etc. This type of file will be common for me (4k MKV with HDR and/or DV) as I upgrade my collection. If I had to I can keep a lower quality file for this kind of use case, however I don't feel I should have to either. That is the magic of Emby server if it is backed with the right hardware to make the dream happen. 😎

 

embyserver.txt HWA - ffmpeg-transcode-5bb6e1c8-99d6-4d24-a099-b1e137f3c91a_1.txt Software - ffmpeg-transcode-7afc8cd5-43f2-4f26-a519-4fe4f135cff7_1.txt

Link to comment
Share on other sites

  • 2 weeks later...
bungee91

Update and more information and logs to share in support of this issue.

Some follow-up thoughts and previous questions or assumptions to discuss:

  • CPU bound?
    • Shouldn't be, my CPU is more than capable of performing this action in real time, and I have tested this same condition completely with software decoding on an ATV client with perfect playback (logs of that above).
  • The file attempts to direct play
    • This makes no sense, and I can see this on the Dashboard in Emby when playback is started sometimes.
      • The user profile is hard set on 4Mbps on the server and this is not being respected for some reason sometimes.

New test and more information for the same user with a similar file (MKV, 4K, HDR, DV...), movie Wonka.

The first playback attempt it played as expected, however (for some reason) at a 1Mbps quality setting confirmed on the Dashboard Now Playing section. Back out of file (stop playback), resume playback. It attempts to direct play and fails. Stop. Play from beginning. It attempts to direct play and fails.

See attached logs in support of this. Again I do not have this issue on ATV clients, web browser, etc. Maybe this will be resolved by a Roku app update 🤔 uncertain as you mentioned some things in testing, etc. However on the server side the lack of it abiding by the quality selections and likely other issues is causing this to fail.

I will provide any other testing or files in support, just let me know. For now I have converted the file to MP4 4Mbps and can confirm the user can play these back, however that is more than expected to be the case.

Thanks.

 

embyserver-63842687999.txt ffmpeg-transcode-20de5d18-d6a1-4e51-9f86-b5285765a87a_1.txt ffmpeg-transcode-25b0e9eb-1ff7-4fab-b94b-2db254002f49_1.txt ffmpeg-transcode-00626a3d-6a74-4bf7-95fe-d55fe7813674_1.txt ffmpeg-transcode-62345b97-8523-4c15-abe4-f3f92f3c8f48_1.txt ffmpeg-transcode-a118cfe4-d40d-4e73-aab5-9209592ed8b4_1.txt ffmpeg-transcode-d0547825-8891-481e-b364-8f36d9dcd4ad_1.txt ffmpeg-transcode-db4295e0-ac4d-4d18-91a4-ea4b598afee1_1.txt

Edited by bungee91
Link to comment
Share on other sites

bungee91
2 minutes ago, Luke said:

Is this only an issue when tone mapping?

I don't believe so as I have both hardware and software tone mapping currently unselected as there was an issue a while back with some file types, HWA and the beta. More than willing to turn it back on if that being unselected is causing an issue. Let me know. Thanks 

Link to comment
Share on other sites

It would be helpful to know the answer to that, yes.

  • Like 1
Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...