Welcome to SharpCaster Discussions!

[Tapanila]

👋 Welcome!

We’re using Discussions as a place to connect with other members of our community. We hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

To get started, comment below with an introduction of yourself and tell us about what you do with this community.

[RobertK66]

Hi,
I am using your code (for a long time now) to achieve my single requirement: "Make an easy to use 'Audio-Caster' – Webradio/Cd Player for Windows PC"
Web Radio being the easy part. There you are ready with a single load media command. But for having a ‘fire once and forget - Load and play one CD” I had to find out some basics about queue handling with the Chrome-Cast APIs.

As I see you are retfactoign the library to use more up to date NET versions, I do also revisit my code now. Since your fix for #161 (thx. again, for that), I am able to add my ‘queue’-customizations with your easily accessible service-oriented approach now (see https://github.com/RobertK66/HomeAudio/tree/main/QueueCaster for details).

Nevertheless, there are some minor quirks with this.
• First (and easy to address): I needed to clone the class MediaSessionMessage because this abstract base class unfortunately is not available as public class. So, in order to subclass my own messages, I simply copied it to my namespace here.
• Then I had to add some properties to the MediaStatus class. As this also introduces cast problems when another/different ‘class definition’ with the same name is used, I had to ‘overwrite’ all Methods/Messages using this Status class.

I have no Idea (yet) how the second issue could be solved more elegant. But as I saw your discussion folder here, I decided to use this as little feedback hub. Maybe There is some easy way to get around with existing code or you could think of introducing some other way of ‘class overwrite’ or ‘protocol detection’ in the existing IOC Container.

Thx. and looking forward to use and improve on new versions ;-),
Robert

[Tapanila]

The 1st is very good find. If you submit a pull request I would gladly accept otherwise I will take a look at that after easter holidays.

The properties you added to MediaStatus class are generic or specific to your implementation?

[RobertK66]

I only added the 'items' array and the 'queueData' element documented here.

If I remember this right, all of the AppIDs I tested with, could handle it (and also the QueueLoadMessage, QueueNextMessage, QueuePrevMessage worked with all of them).

I never implemented my own specific ‘device application’ for the chromecast audio (‘renderer’). With help of your code I wrote a C#-‘Controller Only’ Client. With this I can load my media URLs (hosted on the local network or web radio stations from the internet) to the speaker. Once the queue is set up playing continues as long as the media stream(s) are reachable for the speaker device. No dependency to the C# client being connected or controlling some media/track changes at all.

[Tapanila]

Thanks. I think I can fix the 2nd by adding those to the default implementation

[RobertK66]

Ok, having queues in the base impl would solve my issue at all ;-). But I don’t know if this can be done without changing to much for other use cases.

For this or other/further customizations I would suggest something like I wrote here (in ListAllMessageClasses() ): https://github.com/RobertK66/HomeAudio/blob/main/QueueCaster/ChromecastClient.cs

If you provide a constructor where an optional (list of) assembly(s) with message classes could be passed in, then advanced users can write their own versions of every Message class. Constructor can make sure that only one class per Name exists (and the customization ‘overwrites’ the base impl)!

Or one could deliver a separate ‘standalone’ dll with a special model version, or the ‘base-dll’ comes as separate one only used if no other is provided …..

[Tapanila]

Somehow missed this message completely. I think having a constructor where you can decide your own assembly(s) would be the best option. Currently swamped by daily work so I will come back to this on November.

[RobertK66]

Hi,
after some Novembers passed 😄 , I revisited this project. As I now want to use my code extensions in more than one solution, I decided to write the code as addition of the base library. Doing so I also wrote some new Unit Tests and checked them with my JBL Speaker device.

I am not sure if you have time and are in the mood to accept changes as pull request on this ancient repos. If so, I would invest some more time to give overview of 'known device differences' in the Unit Tests. ( Also I do not succeed yet to run them all at once because there are some issues with the device left in different states and the sequence of tests does matter here 😢 )

feel free to see https://github.com/RobertK66/SharpCaster/tree/queuecaster for my current state of code

[Tapanila]

I'm totally fine with accepting pull requests

[RobertK66]

Great and thx., Here #294 you are 😄 .
I am still not really getting all issues around the #226 fix ( 567212a + 5d8605e ), but I do need this code in my Clients and I wrote a Test where I can proof the fix with manually operating my JBL Speaker device during this test. I think this is somehow related to the threading model of the User application. See also the XUnit Problem with default "parallelAlgorithm". IMHO this causes similar deadlocks in the test runs itself!

[Tapanila]

Thanks a lot for the pull request.
Especially the logger changes are amazing!

I took it into a branch queuecaster and made some changes: 43788e4

Mainly changed few additions to match existing style and moved queue messages to different folder and namespace.
Also added few fields to Queue classes

[Tapanila]

@RobertK66 just noticed that I didn't have a code in place to properly notice when connection was disconnected. So now there's timer on heartbeat channel that should raise the disconnected event properly. Thank you on your work with the pull request. Because of that I now looked through all the issues that have been left open and fixed that issue :).