Emby server can't correctly stream/control MKV files on Chromecast HD

[softworkz 5066]

1 hour ago, cayars said:

I'm going to ask @softworkz to jump in looking at the logs in the post above this one to see if he sees any problem or has any special tests to try.
Softworkz I've teamviewed in with him going over this and did a couple tests.  One set of tests was playing back from his server remotely from my location on a new Chromecast which does not have the issue.  Then reversing this and casting to his chromecast something from my system which plays back fine for me but again, not for him.

One thought I had was that he has both old (original CC) and the new CC he's flipping back and forth using.  Could this be causing an issue confusing Google's casting by somehow getting the capabilities wrong or mixed up when the Origin=https://mediabrowser.github.io? I ask because it seemed like the dashboard was getting mixed up on which device was playing.

I think, @Luke can better answer that, I never had a ChromeCast myself.

[Carlo 4560]

Can you take a look at it in general?
Might be helpful to understand why ffmpeg is spawned so many times and why the logs are cut off.

[bassie112 3]

Just small update from my side:

-Native emby android tv app seems to work fine now on ccwgtv4k since (one of) the last updates. No stutter, unsupported audio is converted correctly by transcoding (I manually selected supported formats in the ccwgtv4k settings menu and enabled passthrough+conversion in the emby app), skip/resume works fine. Great!

-Casting still same issue: when transcoding the same file as above (due to unsupported audio format) I cannot skip/resume (audio plays, video freezes).

 

[nospotify 184]

@cayars @Luke Here are two more examples of people facing the same problem:

 

 

 

[kingmustard 14]

33 minutes ago, wordlover said:

@cayars @Luke Here are two more examples of people facing the same problem:

 

 

 

Me, too:

 

[Carlo 4560]

4 hours ago, wordlover said:

@cayars @Luke Here are two more examples of people facing the same problem:

 

Appreciate the link. So strange as I've done my testing using Chromecast with Google TV 4K version and haven't been able to reproduce the problem.

I do not have any original Chromecasts online just the newer 4K version and can't help but wonder if the problem shows up when different generation of Chromecasts are seen by Google at the WAN port.  Perhaps it's getting confused on ability of the devices. It has to be something strange like that for it to only affect certain people and not others.

Carlo
 

[bassie112 3]

4 hours ago, cayars said:

Appreciate the link. So strange as I've done my testing using Chromecast with Google TV 4K version and haven't been able to reproduce the problem.

I do not have any original Chromecasts online just the newer 4K version and can't help but wonder if the problem shows up when different generation of Chromecasts are seen by Google at the WAN port.  Perhaps it's getting confused on ability of the devices. It has to be something strange like that for it to only affect certain people and not others.

Carlo
 

May be, I have the original 4k version but hooked up via the lan adapter (not wifi).

[Carlo 4560]

I shouldn't improve, but just to make sure, could try a couple movies on wifi vs lan adapter just to see if there is any playback difference?

[bassie112 3]

10 hours ago, cayars said:

I shouldn't improve, but just to make sure, could try a couple movies on wifi vs lan adapter just to see if there is any playback difference?

Tried with original adapter on wifi but no difference to ethernet.

[nospotify 184]

Any progress on this @Luke? I first reported these problems three months ago, and others have, too, in this thread and others. Is the issue with transcoding? Incompatibility with the latest Chromecast dongle software? Even an inadvertent touch of playback controls (when using CCHDwGTV, for viewing HD video files that can't be played properly via the original Chromecast dongle) means there is literally no way to resume playback without restarting from the beginning and letting it play until it catches up to where the glitch occurred - 30, 60, 90 minutes, etc.

[kingmustard 14]

An update: I was at a friends and connected my Samsung Galaxy S5e tablet the TV via a Type-C dongle to the HDMI port on the TV and it happened then, too.

Works fine on the tablet itself.

Can't just be a Chromecast issue and as the same thing occurs with Plex, it can't just be an Emby thing, either.

[nospotify 184]

Interesting. I have not had any playback problems except via the new CC dongle.

[nospotify 184]

OK @Luke and @cayars, here is a full package of files demonstrating the continuing Emby-ChromecastHD problems, this time with direct comparisons to correct playback on the old Chromecast. I finally found a movie that plays on both devices and still breaks when trying to resume or change position when casting to the new CC.

Situation: cast and played a movie to CCHD for 1:15:00 or so, then paused it. A few minutes later came back to resume playback, but CC connection had been lost by Emby, so  I reconnected and tried to Resume. Nope. Same problems as reported above and above and above in this thread, by multiple users: couldn't resume, then after restarting from the beginning, I couldn't return to the 1:15 time, or any other time.

On a whim I tried to playback on old CC, and this file worked. I was able to cast, play, jump to 1:15, and watch the movie. Now attached are server log of this entire process, all ffmpeg files, and the media info screen. This HAS to give you whatever you need to figure out why Emby isn't working properly with the modern Chromecast HD device and most updated software, yes?

embyserver.txt ffmpeg-remux-2caf23b4-0be2-4424-b094-a76f25cd4ee0_1.txt ffmpeg-remux-8d607799-5ba0-4dc7-9085-37fdb5c81a25_1.txt ffmpeg-remux-20bf31d9-eef8-47d4-8007-ff66a42a2149_1.txt ffmpeg-remux-20e7fc1b-81a7-4538-8efa-63dc2a4970ed_1.txt ffmpeg-remux-27e11c81-2b34-4c45-8a83-e4c9ecafd83c_1.txt ffmpeg-remux-64ff8c41-4e5a-4244-a176-ce70cd9317c8_1.txt ffmpeg-remux-397c0cce-88f2-4e82-9cfa-eeac2722b3a1_1.txt ffmpeg-remux-702b0e51-b8f6-4da8-900c-a596941821a2_1.txt ffmpeg-remux-96530b00-9105-4477-82ee-4f5b8c4ef8b7_1.txt ffmpeg-remux-36136946-87e3-4c17-baae-8c8d8bb2a016_1.txt ffmpeg-remux-a1ce9e0d-a05f-452e-ad21-e454babf1393_1.txt ffmpeg-remux-a7e241d5-d3bb-45fa-9692-5e5197d541ed_1.txt ffmpeg-remux-cf207820-1010-4070-a691-054c74ce604f_1.txt ffmpeg-remux-de239720-a05b-41b8-a7db-abdef583051e_1.txt ffmpeg-remux-eee97717-1d8d-41e3-8908-1d445ef1f10c_1.txt

[Carlo 4560]

Please change your Throttle Method to below and try again to see if this makes a difference.

Thanks,
Carlo

[nospotify 184]

37 minutes ago, cayars said:

Please change your Throttle Method to below and try again to see if this makes a difference.

Thanks,
Carlo

Thanks - unfortunately it's already set that way.

Edited February 21, 2023 by wordlover

[Happy2Play 9780]

8 minutes ago, wordlover said:

Thanks - unfortunately it's already set that way.

Not according to your logs.  Did not look at every log.

ThrottleByStreamBufferSize

Can you test changing to Segment Request instead of Streambuffer size?

Also does disabling Throttling make a difference.

Edited February 21, 2023 by Happy2Play

[nospotify 184]

Just now, Happy2Play said:

Not according to your logs.

ThrottleByStreamBufferSize

Can you test changing to Segment Request instead of Streambuffer size?

Also does disabling Throttling make a difference.

Do these changes require Premiere to actually take effect? 

[Happy2Play 9780]

3 minutes ago, wordlover said:

Do these changes require Premiere to actually take effect? 

Not that I am aware of. 

[nospotify 184]

OK, I tried it with the other two options - no throttling, then throttling by streambuffer size. I restarted Emby Server each time just for completeness of testing. No luck - same behavior as before. All logs attached.

ffmpeg-remux-29892f5d-55e7-4c27-835e-8af917832b0b_1.txt ffmpeg-remux-2cd59e9b-58ac-450b-aa71-41a45ad7c7b2_1.txt embyserver-63812510383.txt hardware_detection-63812510416.txt ffmpeg-remux-6984a5a5-5651-4a6f-bff7-a44853534356_1.txt ffmpeg-remux-ba1d69e3-d421-473f-ac7a-a13d71f506f5_1.txt embyserver-63812510504.txt hardware_detection-63812510525.txt ffmpeg-remux-56d8b0ba-96c6-4264-92e9-c1e259972d9f_1.txt ffmpeg-remux-9f73b6ff-dddb-496e-8411-76710d1a1f95_1.txt embyserver.txt

[Happy2Play 9780]

8 minutes ago, wordlover said:

OK, I tried it with the other two options - no throttling, then throttling by streambuffer size. I restarted Emby Server each time just for completeness of testing. No luck - same behavior as before. All logs attached.

ffmpeg-remux-29892f5d-55e7-4c27-835e-8af917832b0b_1.txt 15.72 kB · 0 downloads ffmpeg-remux-2cd59e9b-58ac-450b-aa71-41a45ad7c7b2_1.txt 15.71 kB · 0 downloads embyserver-63812510383.txt 48.75 kB · 0 downloads hardware_detection-63812510416.txt 233.43 kB · 0 downloads ffmpeg-remux-6984a5a5-5651-4a6f-bff7-a44853534356_1.txt 15.63 kB · 0 downloads ffmpeg-remux-ba1d69e3-d421-473f-ac7a-a13d71f506f5_1.txt 15.95 kB · 0 downloads embyserver-63812510504.txt 73.87 kB · 0 downloads hardware_detection-63812510525.txt 233.43 kB · 0 downloads ffmpeg-remux-56d8b0ba-96c6-4264-92e9-c1e259972d9f_1.txt 18.82 kB · 0 downloads ffmpeg-remux-9f73b6ff-dddb-496e-8411-76710d1a1f95_1.txt 16.2 kB · 0 downloads embyserver.txt 60.72 kB · 0 downloads

Can you select Segment Request, hit save and test again as you only have no Throttling and StreamBufferSize.

[nospotify 184]

No luck. Identical broken behavior. All new logs attached.

hardware_detection-63812511883.txt ffmpeg-remux-d4c9525d-abf0-42f6-b11c-34cb86287a32_1.txt ffmpeg-remux-a947ad8c-2381-4eec-af90-2dbf34c9ce31_1.txt ffmpeg-remux-46e78f20-5902-415a-bbbb-ebe2d3c89f12_1.txt embyserver.txt

[Happy2Play 9780]

I don't have Chorecast so won't be any help but @cayars/ devs now can see all three methods shown in logs.

[Carlo 4560]

It appears these all had throttle turn on.

I'd like to see throttle turned off (no checkbox) in the configuration. Make sure to click the save button at the bottom of the page.

Change the playback to not the use any subtitles.

Question for you.  Once you start playback are you doing anything like trying to backup or stop playback after it appears to not work?
If so, don't click anything after starting playback and let it error out on it's own, then you can click around again.
 

Upload new logs using the settings mentioned.

[nospotify 184]

8 hours ago, cayars said:

It appears these all had throttle turn on.

I'd like to see throttle turned off (no checkbox) in the configuration. Make sure to click the save button at the bottom of the page.

Change the playback to not the use any subtitles.

Question for you.  Once you start playback are you doing anything like trying to backup or stop playback after it appears to not work?
If so, don't click anything after starting playback and let it error out on it's own, then you can click around again.
 

Upload new logs using the settings mentioned.

OK, I turned throttling off and then tried once with subtitles on and with subtitles turned off. In both cases no luck. Some additional info, though:

1. I tried skipping ahead only 30 seconds, and as always the visual on screen jumped to that time and froze, while the app time bar reset to zero and began advancing again. However I let it play, and when the time bar caught up to where I had jumped to (~00:00:45), normal playback began from that point forward: audio, video, subtitles. This of course is no help when resuming at or jumping to farther along in a video, but app and server and CCHDwGTV all caught up with each other.

2. When I skipped farther (second screen shot below), as usual the app time bar reset to zero and began advancing again, while the screen image froze at the image from 46:59. BUT I let it play and when the time bar reached the beginning of the actual movie after the credits, the subtitles appeared on screen, matching the time in the app's time bar (~00:00:45), but overlaying the still-frozen image from 46:59. To repeat for clarity: subtitles played and matched app time bar, while video image was incorrect and remained frozen. I did not let it run for 45 minutes to see if it matched behavior reported in 1. above. (grin)

3. With subtitles off, same behavior as above (except of course subtitles didn't appear over later image.) 

Is this helpful?

[Carlo 4560]

Emby may be working correctly.

If the media file has any type of corruption in the headers or anything that affects timing the device may not be able to handle it correctly. Emby server itself may not be able to jump to a specific spot in the file either and may have no choice but to start at the beginning so it can correct the timing issues.

This sounds exactly like what is happening to you.

Could you upload this media somewhere and PM me a location it can be downloaded?