Status Update
Comments
ad...@google.com <ad...@google.com>
di...@google.com <di...@google.com>
ni...@hinge.co <ni...@hinge.co> #2
In debug mode you will see: Load failed: cast.o.media.Il.create is not a function
This function appears to be missing in
di...@google.com <di...@google.com> #3
ak...@google.com <ak...@google.com> #4
I am also experiencing this issue. I have 9 chromecasts V3, all bought at the same time and on 2 of them I was not able to cast images using either the
default or styled media reciever.
When comparing the debugs of a working and non working device I found that the non working one is using the canary framework instead of the V3
First of all i checked and this device doesn't have the Preview program on, how come it gets beta code ?
The error is as stated above on the cast.o.media.Il.create function
Non working canary
c = c.startsWith("image/") ? cast.o.media.Il.create(b) : .L(new hu(b,ku))
Working V3
c = c.startsWith("image/") ? .K(new ot(b)) : _.K(new Nt(b,Qt))
da...@gmail.com <da...@gmail.com> #5
ni...@hinge.co <ni...@hinge.co> #6
Can you also confirm whether this is happening with our latest version? You can try the preview URL that can be found here:
ni...@hinge.co <ni...@hinge.co> #7
So I created a custom reciever app pointing to the preview cast reciever version and I have the same error
It looks like the bug is also present in the preview version.
The problem I have is even if I specify to use the v3 cast reciever (
Why this chromecast in particular has this behavior ?
serial number is: 1125ADSFDMJ
Is there another version of the cast_receiver_framework.js that i could use ?
Thanks,
xa...@google.com <xa...@google.com> #8
Can you please confirm if this preview version is the same one announced on [Feb 10th (https://groups.google.com/g/cast-sdk-announcements/c/-dLdTPHTvDc) that is now in canary testing?
There are disconnects between the dates in the
je...@google.com <je...@google.com>
am...@google.com <am...@google.com> #9
The SDK version is CAST SDK CAF Version: 3.0.0095 the shaka player loaded is 3.0.10. So apparently not the same as the one announced on Feb 10th (3.0.8).
I attached the whole debug output with the preview framework (
How come some devices use canary and some do not ?
Thanks,
Joris
am...@google.com <am...@google.com> #10
To answer your questions, as we roll out the releases, some devices will see the new release (canary) and others will see the old release until the new release is fully ramped up in production. In Feb we found an issue with Shaka player version 3.0.8 which was fixed in version 3.0.10. We delayed the rollout of the receiver release to get the updated Shaka player 3.0.10 into the release, and that's what's currently in canary (and in preview). (The preview URL will always point to the newest build about to be released.)
For the cssting photos bug reported here, engineering has implemented a fix, and we hope to update the release with the fix tomorrow. We'll do our best to update this bug as soon as the fix is in canary.
bi...@google.com <bi...@google.com>
bi...@google.com <bi...@google.com> #11
We're in the process of updating the preview URL with the fix, which should be in place in an hour or so. Joris or John, once that's in place, would you be able to do quick check against the preview URL with the development version of your apps to verify that this has fixed the problems reported?
am...@google.com <am...@google.com>
am...@google.com <am...@google.com>
ni...@ansman.se <ni...@ansman.se> #12
The
am...@google.com <am...@google.com> #13
Thanks
an...@google.com <an...@google.com> #14
I just tested it and it works now !!
Thanks a bunch for your quick response.
We'll do some more testing in the next few days. We'll let you if we encounter other issues.
Thanks,
Joris
an...@google.com <an...@google.com> #15
Great -- thanks for the quick confirmation! We'll be rolling this fix out to production soon. (Full ramp will be early next week.)
ni...@hinge.co <ni...@hinge.co> #16
I've tested and confirm that the issue is resolved in preview mode, also appreciate your rapid feedback.
As I'm new to building and support Chromecast based applications I'd like to better understand an aspect of the release and testing process.
Was the issue we experienced present in the preview release of Feb 1st or Feb 10th, or were unannounced updates to the preview version made after the fact.
What I want to understand is if we monitor preview releases and test our application regularly with them can we avoid this type of issue impacting us in the future? Based on our admittedly very limited sample of Chromecasts it looks like Canary was in use on 10-20% of devices before this issue was identified.
Description
A -> B -> C where they depend on each other in order using an `implementation` scoped dependency.
Module B provides a composable function that uses a composition local from module C.
If module A does not have an explicit dependency on module C, attempting to preview something that uses this composable function from B in module A leads to the preview failing to render with a `ClassNotFoundException` for the class referenced in module C.
It looks something like this:
```
// Module A
@Composable
@Preview
fun PreviewStuff() {
PreviewContent { ... }
}
// Module B
@Composable
fun PreviewContent(content: @Composable () -> Unit) {
CompositionLocalProvider(LocalStuff provides stuff) {
content()
}
}
// Module C
object LocalStuff {
private val LocalStuff = compositionLocalOf< Stuff?> { null }
val current: Stuff
@Composable
get() = LocalStuff.current
?: findStuff()
infix fun provides(stuff: Stuff): ProvidedValue<Stuff?> = LocalStuff(stuff)
}
```
------------------
Studio Build: Android Studio Iguana | 2023.2.1 Beta 1 (also happens on Jellyfish canaries)
Version of Gradle Plugin: 8.2.1
Version of Gradle: 8.5
Version of Java: 21
OS: macOS Sonoma 14.2