Continuing problems playing mkv files via ChromecastHDwGTV

[wordlover 104]

I am going to lose my mind. Please read the past dozen entries in this thread above. We moved the conversation to the issue of video remuxing of apparently flawless files, because with an example documented above, ffmpeg DOES NOT HAVE A PROBLEM with burning in subtitles when casting to Old CC, according to the ffmpeg logs above (as @ebrsays re: the most recently listed logs right above, there seems to be no difference in ffmpeg processing of this latest tested file), and yet EMBY does not cast it properly to CCHD. This is starting to feel like you're trying to gaslight me. I have been crystal clear, I have posted video files, I have posted logs, I have tested in multiple ways, but every time we get to a point where it seems absolutely clear the issue is about EMBY, one of you wanders off on a tangent. PLEASE READ THE DETAILED POSTS AND LOG FILES RIGHT ABOVE IN THIS THREAD. I hate raising my voice but this is beyond absurd and it is utterly disrespectful to not read the information earlier in a thread.

[ebr 14949]

19 hours ago, wordlover said:

what does "differences in the implementation on the CC devices" mean?

I mean in the built-in software on the device itself.

19 hours ago, wordlover said:

Where does that show up in the Emby log or ffmpeg files

I could not find evidence of that in the ffmpeg log - thus my thinking it might be just on the device that is happening.

Let's wait until SW can take some time to have a look at the logs.  Thanks.

[wordlover 104]

9 hours ago, ebr said:

I mean in the built-in software on the device itself.

I could not find evidence of that in the ffmpeg log - thus my thinking it might be just on the device that is happening.

Let's wait until SW can take some time to have a look at the logs.  Thanks.

As additional info/reminder for SW, the EMBY software on my android devices (Samsung tablet and Pixel phone) has timeline resetting to zero when casting only to CCHD.

[softworkz 3341]

On 7/29/2023 at 7:12 AM, wordlover said:

I have posted video files, I have posted logs, I have tested in multiple ways, but every time we get to a point where it seems absolutely clear the issue is about EMBY, one of you wanders off on a tangent. 

First of all, thanks for your patience and thanks for all the logs and testing!
Quick disclaimer: I haven't been involved in development of Chromecast support and I don't even own one, so I don't have all answers, but these:

The logs have been very useful - thanks for the 1,2,3,4 naming as there's no way to distinguish by target device, because for the server, that is the Android app.

The reason why you are seeing two ffmpeg logs in both cases is that once you are skipping forward (like those 30s) and the server hasn't transcoded up to that point, it starts a new transcoding session, starting at the target time (0:00:42 or 0:00:46 in the "second logs" 2 and 4) in order to allow you to continue watching asap.

I'm glad that we have reached a point already, where the earlier suspicions have been ruled out, and I can confirm that @ebr is right: there's absolutely no difference between what Emby is doing in both cases (devices): What's happening at the server is precisely the same thing for both devices! (....in the 1234 logs).

On 7/29/2023 at 7:12 AM, wordlover said:

[...] according to the ffmpeg logs above (as @ebrsays re: the most recently listed logs right above, there seems to be no difference in ffmpeg processing of this latest tested file), and yet EMBY does not cast it properly to CCHD
[...]
where it seems absolutely clear the issue is about EMBY [...]

If you're asking about who might be the culprit, then there are probably some like the following possibilities:

• Emby has an erroneous ChromeCast implementation, which has been working just accidentally on earlier ChromeCast devices while newer models don't tolerate that error anymore
• A breaking change has been introduced in the cast protocol  - to which Emby hasn't adapted
• One or more of the newer CC devices have a bug or limited capabilities which causes them to not support the exact same set of capabilities like older devices

Either way is possible - I can't tell which one it might be a this time.

It's clear that an advertised feature should be working, but I also want to tell you that I don't find it very motivating when you say that the reason why you want this (clearly inferior and clearly just secondary or tertiary choice of method) to be working is to save $5 per month. Yet I still thank you for reporting this issue in all detail. 

Despite my agnostic state towards CC, I'd have some interesting experiments to try if you like:

1. Skipping within transcode buffer
   The way of skipping had involved a restart of transcoding in all the examples. It would be interesting to see whether it would work when skipping only within the range of transcoding. For this test, you'd need to:
   • Install the Diagnostics plugin from the catalog
   • Disable Throttling in transcoding settings
   • Test
     • Start playback, but wait a bit longer than 10 seconds - e.g. 5 minutes
     • The Diagnostics plugin adds a new menu "User Sessions" to the Server Dashboard. 
       There you can watch playback sessions and see the current range of the transcoding buffer
     • Try to seek to positions within that range and see whether it works
2. Start Playback with "Resume"
   This is to test whether playback is working when the initial playback request is not starting at the beginning but somewhere in the middle
   • Test
     • Play the movie in a way which is working (no issue when skipping) for a while
     • Stop playback
     • Try to playback on the new CC device by using "Resume" instead of Play
3. Try to eliminate start_from_zero from ffmpeg commands
   I'm not sure whether the Diagnostics plugin which is available for the stable version has the ffmpeg command line replacement feature, but in case it does...
   • Test
     • Go to the 'Diagnostic Options' on the Server Dashboard
     • In the ffmpeg parameter replacement text boxes, 
       • Enter -start_at_zero in the first one
       • Leave the second one empty
     • Try playback and skipping on the new CC device

Thanks,
softworkz

Edited July 31, 2023 by softworkz

[wordlover 104]

@softworkzThanks for your thorough and helpful comments - I will do all the testing you suggest and report back.