HQPlayer + Muso

[jeremyb]

2.3.19

Allow Remote Server to start if current player is playing a stream

HQPlayer:

- More hqp logging to help diagnose issues

- Reduce comms when playing track 1

[bibo01]

After a quick test, it seems to work fine.

However, I also tried to exit HQPlayer and reopen it. In this case I could queue tracks in Muso but they were not sent to HQPlayer. I could not reestablish connection between the two.

What is that little icon on top right in Queued Music for? "Go to Playlist"???

[jeremyb]

After a quick test, it seems to work fine.

However, I also tried to exit HQPlayer and reopen it. In this case I could queue tracks in Muso but they were not sent to HQPlayer. I could not reestablish connection between the two.

What is that little icon on top right in Queued Music for? "Go to Playlist"???

 

I would probably expect issues if I closed & re-opened HQPlayer - but it should re-connect if you select the player again. However I'll see what I can do to make it auto-reconnect.

 

Go to Playlist is supposed to navigate to the native playlist in whatever player is current, so in the case of Winamp for example it should focus on the app itself so you can see and manipulate the playlist. I seem to remember I had issues getting it to focus on HQPlayer though - if it can't be done I'll hide that icon.

[jeremyb]

I would probably expect issues if I closed & re-opened HQPlayer - but it should re-connect if you select the player again. However I'll see what I can do to make it auto-reconnect.

 

Actually it does seem to auto-reconnect for me.

[jeremyb]

Muso release 2.3.20:

Make HQPlayer "Go to Playlist" focus on HQPlayer window.

Implement timeout in HQPlayer TCP socket to improve robustness.

Make lost connection to HQPlayer visible in NP info (clear on re-establishing connection).

[shadowlight]

Is there a native iOS or Android remote available to control Muso. I have been reading up on Muso and HQPlayer integration and I cannot seem to find an answer for one question.

 

TIA

[jeremyb]

Is there a native iOS or Android remote available to control Muso. I have been reading up on Muso and HQPlayer integration and I cannot seem to find an answer for one question.

TIA

 

It's not a native app, but Muso exposes a web port on your local network to you allow you to remote-control it from any browser from any device connected to your local network (but Muso must remain running on a windows PC to act as a server).

[Geoffrey Armstrong]

I must be doing something obviously wrong. I installed the latest version 2.3.20 and HQP 3.8.2 on Win 10. If I launch foobar 2000 I can connect and play through it from Muso.

 

If I quit foobar and launch HQP, Muso doesn't find HQP as an available app and won't connect to it.

 

Same with 3.8.1

 

I tried when running HQP from its default location and from Ram disk. Neither worked.

 

I like the approach you've taken with Muso and would love to try it with HQP.

 

Please set me on the right track.

 

Thanks,

 

Geoff

[jeremyb]

I must be doing something obviously wrong. I installed the latest version 2.3.20 and HQP 3.8.2 on Win 10. If I launch foobar 2000 I can connect and play through it from Muso.

 

If I quit foobar and launch HQP, Muso doesn't find HQP as an available app and won't connect to it.

 

Same with 3.8.1

 

I tried when running HQP from its default location and from Ram disk. Neither worked.

 

I like the approach you've taken with Muso and would love to try it with HQP.

 

Please set me on the right track.

 

Thanks,

 

Geoff

 

Did you turn on & configure HQPlayer in Muso's Tools/Options (Players/Misc tab)?

[Geoffrey Armstrong]

Did you turn on & configure HQPlayer in Muso's Tools/Options (Players/Misc tab)?

 

Thanks. Working now. I thought it had to be something obvious. I did look in options before; but somehow missed that tab.

 

Geoff

[jeremyb]

How many HQPlayer users would want to run Muso on a different machine to HQPlayer? Now that Muso communicates with HQPlayer through a TCP socket, this should be possible, but I'll only look into it if there is some demand.

[bibo01]

Personally I am interested so I can have Muso running on a Win PC and HQPlayer on a Linux PC.

[jeremyb]

I would probably allow the config to specify both a local HQPlayer and one remote HQPlayer (so you could select either from the players list) - unless there is a strong requirement to specify a list of multiple remote players.

[bibo01]

You may do the same for RAMdisk.

[jeremyb]

You may do the same for RAMdisk.

Allow a different ramdisk per player? So that might be a remote ramdisk on each HQPlayer host?

 

What I couldn't do on remote players is to allow a config override or to auto-start it - those would apply to the local instance only.

[skipspence]

How many HQPlayer users would want to run Muso on a different machine to HQPlayer? Now that Muso communicates with HQPlayer through a TCP socket, this should be possible, but I'll only look into it if there is some demand.

Hi Jeremy

My personal wish were if you could establish a rock solid connection between them on local TCP instead,- maybe there wouldn't be endless disconnections on Remote etc. Maybe it's me alone, - I'm testing in 2PC setup: server with HQPlayer+Muso with whole number of terabytes and NAA as renderer. To run them separately, and NAA on 3-rd PC then?... Why?

[jeremyb]

Hi Jeremy

My personal wish were if you could establish a rock solid connection between them on local TCP instead,- maybe there wouldn't be endless disconnections on Remote etc. Maybe it's me alone, - I'm testing in 2PC setup: server with HQPlayer+Muso with whole number of terabytes and NAA as renderer. To run them separately, and NAA on 3-rd PC then?... Why?

 

I thought we were getting there with connection solidity - which is why I was starting to shift focus to the next task.

[skipspence]

I thought we were getting there with connection solidity - which is why I was starting to shift focus to the next task.

No problem - don't stop it anyway. Thanks for your time and your priceless efforts again!

[skipspence]

OK folks, does anybody got this error once starting Muso + HQPlayer?

 

It's no matter if firewall is on/off or address and port specified in firewall advanced security settings...it persists.

More strange that it can work through this error, but there are issues controlling Muso from remote device presumably because of this: once I got it to play from Remote, there's no NP update, nor tracks queuing from the Album page anew.

 

I attach screen with hqp/muso logs asking the developers please to insight.

(with Jeremy I already discussed this issue privately but regrettably with no results)

 

Thanks in advance for any new ideas

~

[jeremyb]

OK folks, does anybody got this error once starting Muso + HQPlayer?

 

It's no matter if firewall is on/off or address and port specified in firewall advanced security settings...it persists.

More strange that it can work through this error, but there are issues controlling Muso from remote device presumably because of this: once I got it to play from Remote, there's no NP update, nor tracks queuing from the Album page anew.

 

I attach screen with hqp/muso logs asking the developers please to insight.

(with Jeremy I already discussed this issue privately but regrettably with no results)

 

Thanks in advance for any new ideas

~

Does this only happen when you let Muso auto-start HQPlayer perhaps? If so then it's probably trying to communicate with it before it's fully ready, but it seems to recover to allow later communication. If you weren't looking at the logs I don't think you'd notice a problem in muso desktop.I couldn't see from the logs you sent me any evidence of remote not working following this.

[skipspence]

Does this only happen when you let Muso auto-start HQPlayer perhaps?

Yes. There is no remote once I start HQPlayer alone.

If so then it's probably trying to communicate with it before it's fully ready, but it seems to recover to allow later communication. If you weren't looking at the logs I don't think you'd notice a problem in muso desktop.

I don't see any recovery evidence in the logs.

I couldn't see from the logs you sent me any evidence of remote not working following this.

The logs don't show any evidence of remote action at all. Seems like remote and app itself live their own lives. I can post the end of the log too.

[jeremyb]

I don't see any recovery evidence in the logs.

 

There is since it later shows:

01:< 191.834> Connect Player HQPLAYER HQPlayer

01:< 191.834> P:new

01:< 191.834> Q: Start

05:< 191.834> Q: PRODUCER CONSUMER QUEUE -- WORKER THREAD

05:< 191.834> Q: Waiting...

01:< 192.866> Player: HQPlayer

01:< 192.867> Register player events

01:< 192.869> Connect OK

08:< 192.946> HQ: Start TCP Reader

01:< 228.508> Remote Control

01:< 228.508> Needs admin privilege

01:< 228.509> Elevate2:

 

The logs don't show any evidence of remote action at all. Seems like remote and app itself live their own lives. I can post the end of the log too.

 

The elevate message shows you are restarting muso once you turn remote on, which explains why there is no further evidence of remote issues, since it restarts by default WITHOUT diagnostics. In order to start muso elevated in the first place, set it's icon to always "Run as Administrator" and do the same for the diagnostics icon. Then start it with diagnostics, turn remote on (should no longer offer to restart as admin), then check the comms and send me muso2.log when you notice issues.

 

Try this with and without having HQPlayer started before you start muso to see if that makes a difference - muso should connect to an already running instance.

[jeremyb]

The other thing I've noticed is that sometimes HQPlayer does take a while to start up. So if you let Muso auto-start it (with Muso-specific config or without) and it can't establish a connection with the process in 2 seconds, it will appear with a "Disconnected" status (and this is when you get the error about the target machine actively refusing the connection), so you then have to wait until HQPlayer is visible and then select the player in Muso again - upon which it should connect no problem.

[jeremyb]

In order to start muso elevated in the first place, set it's icon to always "Run as Administrator" and do the same for the diagnostics icon.

 

It's worth emphasising this point actually. Muso's remote relies on elevated permissions, so it is important to persist the "Run as Administrator" option on the Muso icon if you intend to use the remote regularly. Though Muso does offer to restart with elevated permissions on turning on remote, this should only be used temporarily (eg. if you just want to try remote out).

[skipspence]

It's worth emphasising this point actually. Muso's remote relies on elevated permissions, so it is important to persist the "Run as Administrator" option on the Muso icon if you intend to use the remote regularly. Though Muso does offer to restart with elevated permissions on turning on remote, this should only be used temporarily (eg. if you just want to try remote out).

Hi Jeremy,

Though I always knew about the "Administrator" option and I set it to Muso start, I didn't do so in Diagnostic start, and this explains why it's not remote activity in the log. But is it possible to do it simple by adding option in Remote settings: start Remote when Muso starts, or just add an argument in Task scheduler for auto start Muso with remote?