I'm pretty new to Rust, but I think the StatusEntry and others could derive the Copy and Clone too so one could make helpers.

E.g. I've made a helper defined like this:

pub trait BaseMediaReceiver {
    fn play(&self);
    fn pause(&self);
    fn stop(&self);
    fn cast(&self, url: &str);
    fn get_current_time(&self) -> Option<f32>;
    // fn get_status(&self) -> Option<StatusEntry>;
}

But I can't implement the get_status because the StatusEntry is not copyable. Maybe I'm not yet understanding the Rust perfectly. However I keep getting type &StatusEntry from a status.entries.first().unwrap() call and I can't convert it back to StatusEntry because it's not copyable.

Thanks, great library! I've used JavaScript libraries for chromecast before, but boy I don't like those.

Hi,

I am interested in an async module that communicates with my Chromecast as part of a web application.

Would you open to collaborating on this? Alternatively I can make an async version and link back to this repo as the source of much of the work.

The idea is similar to the one in https://github.com/muammar/mkchromecast which sadly has quite a latency.

Hi

I have a use-case in which I want to auto resume a media item from a certain position when loading a media item within the default media receiver of Chromecast.
The current implementation of the load function hard codes the current_time command field to always be 0 (see media.rs#L578).

So if it would be possible that we can get an option to configure this command field, it would be much appreciated.

Doc references: https://developers.google.com/cast/docs/media/messages#Load

Hi,

both my Cast devices started to return MEDIA_STATUS messages which fail to parse with rust-cast. This breaks both my own app, but also your rust-caster example.

I noticed that the "supportedmediaCommands" field in StatusEntry is set to 247772, which clearly wont fit into u8.

Going through the ChromeCast developer documentation I don't see anything that describes what those upper bits are for, the doc only talks about those low 6 bits you already covered...

DEBUG 2018-10-14T08:59:38Z: rust_cast::message_manager: Message received: 
    CastMessage { 
        protocol_version: Some(CASTV2_1_0), 
        source_id: Some("1389b262-07d0-4354-bb20-1e42155b67ef"), 
        destination_id: Some("*"), 
        namespace: Some("urn:x-cast:com.google.cast.media"), 
        payload_type: Some(STRING), 
        payload_utf8: Some("
            {
                \"type\":\"MEDIA_STATUS\",
                \"status\":[{
                    \"mediaSessionId\":1,
                    \"playbackRate\":1,
                    \"playerState\":\"IDLE\",
                    \"currentTime\":0,
                    \"supportedMediaCommands\":274447,          // 0b1000011000000001111
                    \"volume\":{
                        \"level\":1,
                        \"muted\":false},
                    \"media\":{
                        \"contentId\": \"http://192.168.1.42:8000/Test.mp4\",
                        \"streamType\":\"NONE\",
                        \"contentType\":\"\"
                    },
                    \"currentItemId\":1,
                    \"extendedStatus\":{
                        \"playerState\":\"LOADING\",\
                        "media\":{
                            \"contentId\":\"http://192.168.1.42:8000/Test.mp4\",
                            \"streamType\":\"NONE\",
                            \"contentType\":\"\"
                        }
                    },
                    \"repeatMode\":\"REPEAT_OFF\"
                }],
                \"requestId\":0
            }"),
        payload_binary: None, 
        unknown_fields: UnknownFields { 
            fields: None 
        }, 
        cached_size: CachedSize { 
            size: 0 
        } 
}

Something like this: categories = ["command-line-interface"].

-m, --media <media_handle> Media handle (URL for image or video, URL token for youtube video etc.) to load on the Cast connected device.

seems to not support local files?

By using Cow, you need to specify lifetimes on the CastDevice struct. It means I need to specify lifetimes everywhere I use a CastDevice. It's possibile, but it's a bit of an hassle.
Is Cow really needed?

Currently, the builds aren't working on doc.rs, nor on my local nightly build. doc.rs hasn't worked since 0.15.0.

It looks like a bump to the openssl dependency would probably fix it: https://docs.rs/crate/rust_cast/0.8.1/builds/54937

[Media] NotImplemented("ERROR", Object {"detailedErrorCode": Number(104), "itemId": Number(1), "type": String("ERROR")})
[Media] NotImplemented("ERROR", Object {"detailedErrorCode": Number(104), "type": String("ERROR")})

MEDIA_SRC_NOT_SUPPORTED

https://developers.google.com/android/reference/com/google/android/gms/cast/MediaError.DetailedErrorCode

Hi,

Unless I’m mistaken, there currently isn’t any code to discover new Chromecast devices, and the only way to use them is to know the IP address beforehand having discovered it by some other means. Would you consider implementing that or including some examples of performing discovery by other means (I’ve no idea at the moment how to do zeroconf discovery in Rust)?

Hi there, I tested this with the latest Chromecast device: Chromecast with Google TV. The Big Buck Bunny example works just fine, i.e.:

cargo run --example rust_caster -- -a 192.168.15.19 -m http://commondatastorage.googleapis.com/gtv-videos-bucket/sample/BigBuckBunny.mp4

The heavy use of Rc types means I can't construct a CastDevice on one thread and then move or clone it over to another thread (or thread pool) that my proxy server will be running on.

It's pretty common for networked clients to be thread-safe.