Jump to content

Continuing problems playing mkv files via ChromecastHDwGTV


wordlover

Recommended Posts

Can you post one of these episodes up in dropbox, Google Drive or other place and send me the link?
I'd like to try and duplicate your results.

Carlo

Link to comment
Share on other sites

wordlover

@CarloWe did that earlier, and also did a multi hour screen share session. You have had several thoughtful hypotheses that we tested and which turned out not to be the issue. If this is happening with scores and scores of different files, and it occurs only when Emby is streaming to the CCHD, the issue isn't with the files.

Link to comment
Share on other sites

17 hours ago, wordlover said:

it occurs only when Emby is streaming to the CCHD, the issue isn't with the files

Hi.  I think we already established that the core issue is in the files.  You are seeing the "symptom" of this only happening when casting to that particular device but that is not the actual cause.  I believe the cause is that, when casting to that device, we are running the item through ffmpeg and, in that case, with the bad timings in the file, direct seeking does not work.

We may be able to work around this issue and will look into that but the core issue is bad data in the files.

Link to comment
Share on other sites

wordlover

@ebrAs @Carlorequested (above) I ran an example file through MKVToolNix, which found no bad data, and the cleaned output file had the same problems. Direct link to file sent to him, and now to you, via DM. 

Link to comment
Share on other sites

On 6/29/2023 at 3:33 PM, wordlover said:

@CarloWe did that earlier, and also did a multi hour screen share session. You have had several thoughtful hypotheses that we tested and which turned out not to be the issue. If this is happening with scores and scores of different files, and it occurs only when Emby is streaming to the CCHD, the issue isn't with the files.

Yes I remember as we tried it a couple different ideas to rule everything out or find an issue.  Using the same players when connected to my system you couldn't duplicate the issue as my files direct played, but even when I turned down the bitrate on the server to force transcoding it still worked fine, except for the jump ahead which requires the transcoder to catch up process that section before the client has media to display. No way around that, and it's like this on every client that transcodes. That was why I thought it was a media issue back then as well. What I wanted to find out here is why the different playbacks on the two devices

What I did want to verify is the same outcome using your file.  Depending on the nature of what I see it may be easy to script running it across your libraries.

Link to comment
Share on other sites

  • 2 weeks later...
wordlover

So is this an accurate summary of the situation @ebr, @Luke, @Carlo?

1. Chromecast HD doesn't support the full range of audio codecs that the old Chromecast does.

2. Because of this video files with audio in such formats needs to be transcoded when casting to CCHD.

3. The version of FFmpeg that EMby relies on throws errors when transcoding audio on any files with even tiny timing imperfections.

4. Emby devs now know what to modify in your code (or FFmpeg?) so that this transcoding isn't so exacting and thus playback controls will work properly when casting to CCHD from now on?

Link to comment
Share on other sites

12 hours ago, wordlover said:

Chromecast HD doesn't support the full range of audio codecs that the old Chromecast does

Is that true?  You have a reference?

12 hours ago, wordlover said:

Emby devs now know what to modify in your code

If the above is true, then, no we don't.

Link to comment
Share on other sites

wordlover

I thought that is what @Carlolooked up (or @visproduction?) In a different thread about this problem. 

If that isn't the case, then why is Emby transcoding when casting to CCHD and not when casting to older CCs? That seems to be what is causing the problem.

Edited by wordlover
Link to comment
Share on other sites

15 hours ago, wordlover said:

I thought that is what @Carlolooked up (or @visproduction?) In a different thread about this problem. 

If that isn't the case, then why is Emby transcoding when casting to CCHD and not when casting to older CCs? That seems to be what is causing the problem.

Because that's what it's telling us is supported. To my knowledge, Chromecast doesn't support any ac3 or eac3 decoding. so it can only pass it through to something that can decode it. So it depends on what it's connected to that will determine what audio formats are supported or not.

Link to comment
Share on other sites

wordlover

Could you three Emby devs PLEASE confer directly?! This confirms what Carlo or Vis indicated re: new CCHD not handling full range of audio codecs, which for some reason ebr is still questioning. This process is maddening. And ebr said above "I believe the cause is that, when casting to that device, we are running the item through ffmpeg and, in that case, with the bad timings in the file, direct seeking does not work. We may be able to work around this issue and will look into that but the core issue is bad data in the files." This asynchronous process of different devs chiming in at different times and apparently not reading the earlier parts of these threads has been going on for months and months and months. It is now clear what the problem is. Can y'all fix it?!

Link to comment
Share on other sites

Hi.  When I said we may be able to work around the issue it was if the case was that we were simply incorrectly determining the audio support.  I'm not sure that is the case and it is looking increasingly likely that it isn't.

Can you confirm that both of  your CC devices are connected to the exact same equipment for your tests?

Link to comment
Share on other sites

wordlover

Yes - the setups are absolutely identical. The only variable is which CC device Emby is casting to. One sample of hundreds of video files that have the same playback control problem only on CCHD, as well as numerous logs, have been posted above and in other threads and DM'd.

Link to comment
Share on other sites

7 hours ago, wordlover said:

the setups are absolutely identical

Meaning it actually is two different setups?  Or you are taking one TV setup and switching devices between the two ChromeCasts on the exact same port on the exact same TV setup?

Link to comment
Share on other sites

wordlover

Sorry for not being clearer. As I have posted before, it's one setup - either Samsung tablet or Pixel 5a phone running Emby app, casting to original CC in HDMI 1 on Samsung TV, then uncasting, and then casting to CCHD in HDMI 2 port. I have tested every variable: have tried reversing the order (first casting to CCHD then Old CC), have tried reversing theb HDMI ports they're plugged into, have tried removing Old CC from system entirely, etc. etc. etc. etc.

Link to comment
Share on other sites

I apologize if we've been through this and I've just missed it or forgotten but have you tried disabling the permission for audio transcoding for this user and then playing the problem item?  This would just be a test to confirm that the device actually can play the audio in question.

Link to comment
Share on other sites

wordlover
11 minutes ago, ebr said:

I apologize if we've been through this and I've just missed it or forgotten but have you tried disabling the permission for audio transcoding for this user and then playing the problem item?  This would just be a test to confirm that the device actually can play the audio in question.

Where is that setting? I see overall transcoding options, but none just for audio.

Edited by wordlover
Link to comment
Share on other sites

wordlover
6 minutes ago, ebr said:

image.png

Uncheck the audio one.

BOOM! There it is. Fixed. Or at least the standard video file I uploaded for you to test is now playable and controllable here. Apparently the audio transcoding that Emby is doing - but only when casting to CCHD and not to the old CC - is what's causing the playback control problem. Why Emby is trying to transcode audio, only when casting to CCHD, is a separate question I gladly leave to you, in hopes that no other files I try to play will require audio transcoding. (I tested a few others now, too, and all are played and controlled fine.) 

Link to comment
Share on other sites

wordlover
3 minutes ago, Luke said:

Does the file have more than one audio track?

It does not - single "English AAC audio" track.

Link to comment
Share on other sites

wordlover

As Carlo noted upthread:  "EAC-3 AC-3 is supported on the CC Google TV device but we're not sending this audio codec to ffmpeg as a choice. Part of the problem here besides files with dozens of subs and files with bad timings is that we're doing audio transcoding and remuxing when we shouldn't have to." 

Link to comment
Share on other sites

21 minutes ago, wordlover said:

It does not - single "English AAC audio" track.

Are you sure? How many channels is the track?

Link to comment
Share on other sites

wordlover

I am not a tech person - just looking at Emby's screen for each episode, which doesn't show a drop down to select other audio tracks, unlike for other video files. Is there someplace else I should be looking? Did you download the sample file I put on Dropbox a while ago?

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...