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

[wordlover 103]

4 minutes ago, cayars said:

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?

We did that before. This has happened with literally scores of other video files, and ONLY with CCHD, not with the old Chromecast dongle. Emby is not working correctly with the new dongle, which is running the latest Android software.

[Carlo 4330]

I would think if it was a media player issue this issue would be pretty widespread with many people reporting issues as it's a popular media device, but that doesn't seem to be the case.

If you look at the ffmpeg log files you'll see it can't probe the file properly to pull back information it would need to work normally and have the ability to jump to specific time codes. Instead it has to start at the beginning in order to correct this.

If you can send a copy of the file I'd test it on my system as well to see if I get the same results.  I would also try to find the easiest method that could be used to fix the issue so you could try that on any other files you might have an issue with.

The above is of course assuming I'm correct about corrected header in the file.  You could try downloading mkvtoolnix on the file to see if it fixes the issue.

https://mkvtoolnix.download/

17:22:47.434 [matroska,webm @ 000002ba855fdbc0] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
17:22:47.434 [matroska,webm @ 000002ba855fdbc0] Could not find codec parameters for stream 3 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

 

[kingmustard 9]

1 minute ago, cayars said:

I would think if it was a media player issue this issue would be pretty widespread with many people reporting issues as it's a popular media device, but that doesn't seem to be the case.

If you look at the ffmpeg log files you'll see it can't probe the file properly to pull back information it would need to work normally and have the ability to jump to specific time codes. Instead it has to start at the beginning in order to correct this.

If you can send a copy of the file I'd test it on my system as well to see if I get the same results.  I would also try to find the easiest method that could be used to fix the issue so you could try that on any other files you might have an issue with.

The above is of course assuming I'm correct about corrected header in the file.  You could try downloading mkvtoolnix on the file to see if it fixes the issue.

https://mkvtoolnix.download/

17:22:47.434 [matroska,webm @ 000002ba855fdbc0] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options
17:22:47.434 [matroska,webm @ 000002ba855fdbc0] Could not find codec parameters for stream 3 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

 

For the record, this issue is occuring on every video file (thousands of them) I try to cast, so me sending you a copy of any of them would be pointless.

It's not the video files.

[Carlo 4330]

I can only go by what I see and what you provide. The logs all show this issue.

mkvtoolnix can be scripted to process files so it could be ran in bulk if it does fix your issue.

[kingmustard 9]

5 minutes ago, cayars said:

I can only go by what I see and what you provide. The logs all show this issue.

mkvtoolnix can be scripted to process files so it could be ran in bulk if it does fix your issue.

I have all sorts of bitrates, containers, codecs, audio channels, subtitles or not etc. All random sources, from all different years.

Happens to all of them.

It's not the video files.

Edited February 21, 2023 by kingmustard

[kingmustard 9]

I just had a friend play a video until the issue occured.

Logs attached.

There is no remux log as it's was all Direct Play/Stream (though, as I said, the issue occurs with every type of video file).

embyserver.txt hardware_detection-63812612947.txt

Edited February 21, 2023 by kingmustard

[wordlover 103]

I sent you different file with this problem several months ago:

[Carlo 4330]

2 hours ago, kingmustard said:

I just had a friend play a video until the issue occured.

Logs attached.

There is no remux log as it's was all Direct Play/Stream (though, as I said, the issue occurs with every type of video file).

embyserver.txt 98.39 kB · 0 downloads hardware_detection-63812612947.txt 160.68 kB · 0 downloads

I'm not sure what you're trying to show here but these are not settings I would ever recommend anyone use.
Turn on your network firewall as it's your main source of protection.
Turn off UPnP as it allows any device on your network to open and forward internet traffic to any inside device.

With the DMZ server setup you are intentionally pushing all traffic not already forwarded to this server vs stopping it at the WAN.
You're literally exposing every port on this computer to the Internet for anyone to hack as will.

You should close up all the holes and then run a few different virus, malware and exploit checking software on every device in your LAN as they've been open to exploit.

[Carlo 4330]

2 hours ago, wordlover said:

I sent you different file with this problem several months ago:

Yep, it too had header issues that caused timing problems.

Humor me and try downloading and running the the util I mentioned to see if it fixes this issue.

[wordlover 103]

40 minutes ago, cayars said:

Yep, it too had header issues that caused timing problems.

Humor me and try downloading and running the the util I mentioned to see if it fixes this issue.

Just ran it through MKVNix - unfortunately nope, identical problem. See below. What is broken?

 

Edited February 22, 2023 by wordlover

[Carlo 4330]

Don't know. What does the Info Tool show?

Not sure what you did but did you select the option "Fix bitstream timing info"?

[wordlover 103]

(Found the option) Yes, @cayars,  I now selected that "Fix bitstream timing info" option, converted again, and still the same problem. The problem isn't the file. Or any of the many other files that Emby isn't casting (and controlling) correctly -  ONLY to the new CCHD, as reported by multiple users above.

Edited February 22, 2023 by wordlover

[kingmustard 9]

8 hours ago, cayars said:

I'm not sure what you're trying to show here but these are not settings I would ever recommend anyone use.
Turn on your network firewall as it's your main source of protection.
Turn off UPnP as it allows any device on your network to open and forward internet traffic to any inside device.

With the DMZ server setup you are intentionally pushing all traffic not already forwarded to this server vs stopping it at the WAN.
You're literally exposing every port on this computer to the Internet for anyone to hack as will.

You should close up all the holes and then run a few different virus, malware and exploit checking software on every device in your LAN as they've been open to exploit.

If you read the included embyserver.txt, there appears to be many PortMapper errors, so I included a screenshot of my router setup.

[Carlo 4330]

4 hours ago, kingmustard said:

If you read the included embyserver.txt, there appears to be many PortMapper errors, so I included a screenshot of my router setup.

You need to make changes to improve functionality as well as greatly improve security. Basically you need to remove the DMZ so you don't redirect all incoming traffic to a machine not setup for DMZ use.  For best security of your network you want to disable UPnP as it makes it easy for any script or program to exploit your network.  Unload the PortMapper plugin in Emby Server as it won't be able to be used with the changes just made.  Now with a much hardened firewall in place not allowing any inbound traffic that wasn't first initiated from your LAN you will need to setup Poort Forwarding manually for a single port or two that allows traffic to your Emby Server.

This knowledge base article walks you through what's needed for Emby use: (assumes firewall is active, no DMZ and UPnP is disabled).

https://support.emby.media/support/solutions/articles/44002137137-remote-setup

Hope that helps for security, remote Emby use as well as cleaning up the log files. This also removes any casting issues the DMZ might have caused if any.

If you still have issues with casting to the CC after this we will have easier to read log files as well as know it shouldn't be network related.
 

[Carlo 4330]

9 hours ago, wordlover said:

(Found the option) Yes, @cayars,  I now selected that "Fix bitstream timing info" option, converted again, and still the same problem. The problem isn't the file. Or any of the many other files that Emby isn't casting (and controlling) correctly -  ONLY to the new CCHD, as reported by multiple users above.

If you look at the ffmpeg file generated when you play back the media do you see any errors or information showing issues with the file such as what was there previously like this?

17:22:47.434 [matroska,webm @ 000002ba855fdbc0] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

What does MKVToolNix show using info tool?

In your case things are working correctly from a Emby standpoint as it's doing what needs to be done transcoding wise. The files you are playing aren't supported by the device so Emby is Transcoding them. You only have CPU available to use vs GPU so it's not going to be able to transcode super fast but your machine is fast enough to transcode the files in CPU at a rate faster than playback speed. However, if there is a problem with the headers, timing, frames used or bad encoding, Emby Server might be forced to have to start at the beginning of the file transcoding in order to align the tracks to get the timing correct.

What you have to keep in mind is that devices like a CC are designed to playback files in a streaming format or progressive downloads if everything is encoded correctly.  Meanwhile files people acquire or remaster themselves aren't created for streaming but for local playback similar to disc files. Even tools like MKVToolNix are geared to create/fix files for local playback and don't impose what type of frames or quantity/spacing of frames that come into play for streaming.

Many people, myself included pre-process all files before adding them to our systems. This ensures there is always a common 2 channle aac audio track so that audio is never the reason for a transcode. Subs and audio tracks not needed are removed, subs that can be moved external are. video codecs other than h.264, h.265, are reprocessed, etc  While not making streaming files this allows the file to be used far more often as progressive downloads.  Because the files are re-written when pre-processed this also normally removes any issues that cause any type of timing issue.  In a way you can think of this as "transcoding" the file once upfront vs every time the media is played.

Short of having to transcode due to global or user bandwidth limits imposed any transcode needed is an indication that the file isn't optimized for use on your system and could be improved upfront vs dealing with it real-time when played.  Emby is designed to transcode media on the fly when needed but can only do so much when there is an issue with the media file.

I would still like to be able to look at a file or two you have this issue with and test casting it to my Chomecasts as well.

 

 

[Happy2Play 8296]

5 minutes ago, cayars said:

If you look at the ffmpeg file generated when you play back the media do you see any errors or information showing issues with the file such as what was there previously like this?

17:22:47.434 [matroska,webm @ 000002ba855fdbc0] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' (0) and 'probesize' (5000000) options

Isn't that normal as every log I have seen has that for pgssubs?

 

[Carlo 4330]

Interesting observation @Happy2Play.  I don't personally use pgssubs so you could be correct. It could very well be unrelated but something is causing Emby Server/ffmpeg to have to start at the beginning of the file vs being able to jump to the timecode.

I hate speculating what an issue is without being able to see the issue first hand, hence my request for samples of media having the issue. Having a sample or two would allow testing playback casting to the newer CC both starting at the beginning of the file as well as restarting from a previous watch point to duplicate the issue and definitively find the reason for Emby having to transcode from the beginning of the file.  Hopefully find some type of solution as well.

 

[wordlover 103]

@cayars

If there is a problem with all these files, why would this playback error happen ONLY with CCHD and not the old CC dongle?

[Carlo 4330]

Keep in mind it's speculative as I'm not certain without being able to look at the file with tools I have or try to duplicate.  But from what I'm seeing log wise, that is the likely culprit as I see it right now.

Is the old CC dongle also transcoding or does it direct play. If it is transcoding using the same codecs and not having the issue then that could likely point in a different direction.
Can you play back the exact same media on both where it has to start at 15 minutes or so into it?  Make sure you use the same audio tracks and subtitles settings.

I'd still like a sample media file or two to test with.

[Mnejing 21]

So without having looked at any logs, and knowing I had a bunch of hassle with PGS subs at one point... are the subs enabled while trying to playback? Are they being burned in? In my experience, burning in PGS subs causes nasty transcoding.

[kingmustard 9]

18 hours ago, cayars said:

You need to make changes to improve functionality as well as greatly improve security. Basically you need to remove the DMZ so you don't redirect all incoming traffic to a machine not setup for DMZ use.  For best security of your network you want to disable UPnP as it makes it easy for any script or program to exploit your network.  Unload the PortMapper plugin in Emby Server as it won't be able to be used with the changes just made.  Now with a much hardened firewall in place not allowing any inbound traffic that wasn't first initiated from your LAN you will need to setup Poort Forwarding manually for a single port or two that allows traffic to your Emby Server.

This knowledge base article walks you through what's needed for Emby use: (assumes firewall is active, no DMZ and UPnP is disabled).

https://support.emby.media/support/solutions/articles/44002137137-remote-setup

Hope that helps for security, remote Emby use as well as cleaning up the log files. This also removes any casting issues the DMZ might have caused if any.

If you still have issues with casting to the CC after this we will have easier to read log files as well as know it shouldn't be network related.
 

That fixed the Chromecast Ultra issue for me!

I have no idea why it did but it did

[wordlover 103]

10 hours ago, cayars said:

Keep in mind it's speculative as I'm not certain without being able to look at the file with tools I have or try to duplicate.  But from what I'm seeing log wise, that is the likely culprit as I see it right now.

Is the old CC dongle also transcoding or does it direct play. If it is transcoding using the same codecs and not having the issue then that could likely point in a different direction.
Can you play back the exact same media on both where it has to start at 15 minutes or so into it?  Make sure you use the same audio tracks and subtitles settings.

I'd still like a sample media file or two to test with.

I uploaded the logs above, so you can see how Emby was casting to old cc and new cc - can you take a look?

 

[Carlo 4330]

These logs show 4 different CC

chromecast_1676783817958
chromecast_1676787604577
chromecast_1676783911951
chromecast_1676778622058

These 4 CC have 3 different video profiles:

h264,h265,hevc,vp8,vp9
h264,vp8
h264,h265,hevc,vp8,vp9h264,h265,hevc,vp8,vp9

The log files are showing many different playbacks with some FF some startin at a specific timeline, some starting at 0.

Not really helpful to compare  CC1 vs CC2 heads up playing back the exact same way.

Can we grab logs doing the following which should make this very clear.
Pick any media file that gives you this issue and start playing it and advance/rewind it so you can play it and exit it right at the 5 minute mark. Couple seconds off isn't a big deal.
Run the scheduled task to rotate the log file.
Resume playing the media file casting it to the old CC device.
Using a watch/clock give it 5 minutes to play. If it starts to play before the 5 minute mark. Exit playback, grab the server log and ffmpeg log file and upload those as old CC.

Now do the same thing for the new CC device:
Start playing the media file, advance/rewind it so you can play it and exit it right at the 5 minute mark. Couple seconds off isn't a big deal.
Run the scheduled task to rotate the log file.
Resume playing the media file casting it to the new CC device.
Using a watch/clock give it 5 minutes to play. If it starts to play before the 5 minute mark. Exit playback, grab the server log and ffmpeg log file and upload those as new CC.

That should give us a server and ffmpeg log for each CC device that are playing back the same media with a starting time of 5 minutes give or take a couple seconds.
This will provide a good comparison of both devices.

While creating these devices don't do anything other than instructed like trying to pause, FF, RW. All we want to see is casting the playback starting at 5 minutes allowing for up to 5 minutes for it to start playback.

Thanks,
Carlo

 

[kingmustard 9]

8 hours ago, kingmustard said:

That fixed the Chromecast Ultra issue for me!

I have no idea why it did but it did

@wordlover Try adjusting your router settings and see if it works, as it did for me.

Edited February 23, 2023 by kingmustard

[wordlover 103]

6 hours ago, cayars said:

These logs show 4 different CC

chromecast_1676783817958
chromecast_1676787604577
chromecast_1676783911951
chromecast_1676778622058

These 4 CC have 3 different video profiles:

h264,h265,hevc,vp8,vp9
h264,vp8
h264,h265,hevc,vp8,vp9h264,h265,hevc,vp8,vp9

The log files are showing many different playbacks with some FF some startin at a specific timeline, some starting at 0.

Not really helpful to compare  CC1 vs CC2 heads up playing back the exact same way.

Can we grab logs doing the following which should make this very clear.
Pick any media file that gives you this issue and start playing it and advance/rewind it so you can play it and exit it right at the 5 minute mark. Couple seconds off isn't a big deal.
Run the scheduled task to rotate the log file.
Resume playing the media file casting it to the old CC device.
Using a watch/clock give it 5 minutes to play. If it starts to play before the 5 minute mark. Exit playback, grab the server log and ffmpeg log file and upload those as old CC.

Now do the same thing for the new CC device:
Start playing the media file, advance/rewind it so you can play it and exit it right at the 5 minute mark. Couple seconds off isn't a big deal.
Run the scheduled task to rotate the log file.
Resume playing the media file casting it to the new CC device.
Using a watch/clock give it 5 minutes to play. If it starts to play before the 5 minute mark. Exit playback, grab the server log and ffmpeg log file and upload those as new CC.

That should give us a server and ffmpeg log for each CC device that are playing back the same media with a starting time of 5 minutes give or take a couple seconds.
This will provide a good comparison of both devices.

While creating these devices don't do anything other than instructed like trying to pause, FF, RW. All we want to see is casting the playback starting at 5 minutes allowing for up to 5 minutes for it to start playback.

Thanks,
Carlo

 

OK, attached are server logs and ffmpeg files for 5 minute jump&play to OLD and NEW Chromecast dongles. No problems jumping on Old CC. On New CCHD, once the incorrectly-restarted playback reached the jumped-to point (~5 minutes, leaving that still image on screen the whole time) normal playback resumes. What do the logs tell you?

OLD_ffmpeg-remux-05153e26-e434-4d6c-b1e9-eeafb5427e4b_1.txt OLD_ffmpeg-remux-e3e914ef-4f7c-415f-900c-d1c11cc8c372_1.txt OLD_ffmpeg-remux-6656a370-fd0e-41cd-b92a-eacca6774060_1.txt NEW_ffmpeg-remux-970801e2-fded-499d-9060-93de001971f3_1.txt NEW_ffmpeg-remux-d9edb709-f290-48fe-8eeb-a38ecbb0acc9_1.txt embyserver_NEW.txt embyserver_OLD.txt