On buid 1.0.23-rc2-lucky I'm seeing inconsistent behavior when I try to play to server instead of device. Sometimes it will look as if it is playing (song advances on the screen) but no sound from server and sometimes it sets the casting option to that server then it does play. If I then switch to a different server and choose playback to server it casts to the previous server. Is this intentional or a caching issue? Since there are file format restrictions for casting is it currently possible that the server playback option would NOT require casting but instead act as a remote of the server?
On the topic of casting, I've noticed that the app is converting the source file to 128 kbps MP3 in the server's JRiver Conversion cache; is there a setting to NOT convert format/bitrate when casting if the file format is supported by Chromecast?
That sound wonky. When I hear "casting" I think of DLNA broadcasting as one method of playing to another device. ANd then "Play on Server" is basically remote controlling the JRMC server and polling back for info. Your second sentence where you say "Sometimes it will look as if it is playing (song advances on the screen) but no sound from server and sometimes it sets the casting option to that server then it does play." is very confusing. Can you explain this better?
As far as using the "Play on Server" instead of device. There are currently 2 ways to implement the play queue:
1. Manage the play queue on the device so that the JRiver server recieves the individual calls to play a track and it no knowledge outside of what it is currently playing.
2. Send all of the track keys to the JRMC server and let JRiver handle moving between the tracks by the device simply calling Prev/Next.
I currently have #1 implemented but leaning that #2 would be the better solution. I don't think you would have the problems you are seeing. What do you think?
As far as casting the original source format if allowed instead of forcing all to be converted to mp3, I am not there yet but I understand it's benefit. I will add it as a future feature. I just don't know when at this point.
@px I think that you're right about the second option being the better one for server based playback. I think about it as when I choose to have the server play, the app is a remote for the server but when I opt to cast to the server (or another one), the app is the controller. The format change when casting is a minor nuisance but not a showstopper for production launch in my opinion.
I went ahead and took care this and shifted all the work to the server as I think it should be and I think most other implementations are similar. I works ALOT better. Dunno what I was thinking before.
@px Thanks- my poor old S7 can't keep up so I've loaded a small subset of my music on my S23. Using my S23, the server change works for me when the MC35 library selected is running on Windows but not when it's running on Linux (Zorin OS 18 based on Ubuntu 24.04) laptop in my dining room. It works when I connect to my main office pc whether I'm using a MC35 library on that pc or when it is acting as a client of the media-server in the basement. I'll retest the Linux issue when I reboot my main office pc (much more powerful than the laptop) then add a post.
So it seems that the choke point is the oldish Lenovo laptop on Zorin as when connected to my main pc booting into Zorin, both my S7 and S23 can play to the server regardless of whether that pc's access key is pulling the locally located library or acting as a client of the basement Media-server.