support for HQplayer
Re: support for HQplayer
Let me know if the performance is up to scratch. As I said it seemed pretty sluggish to me (hqp-control is slowish to respond to each command Muso issues), but I was adding albums of flac files from a network drive.
Re: support for HQplayer
OK, I have done some quick testing - it works. Good!
Tracks have to queued to be played and, in order to do that, a player has to be available. It means that HQPlayer has be started before Muso, which in a way it's an inconvenience. It would be good if it was possible to bypass that.
It responds to the commands, quicker than expected, at least with albums/tracks in local. I have not tried with albums from NAS. Perhaps you are not familiar with HQPlayer and it needs some time for calculations especially conversions. PCM>PCM is pretty fast though.
It would be good that Playing Now feature was available for HQPlayer (at the moment it is not), otherwise it is not possible to know what track is playing from within Muso.
I could not experiment with Remote. I hope Antonello is going to do that.
All in all, at first sight, a very good first implementation - thanks.
BTW, HQPlayer v3.80b3 is available: http://www3.signalyst.com/bins/beta/
Tracks have to queued to be played and, in order to do that, a player has to be available. It means that HQPlayer has be started before Muso, which in a way it's an inconvenience. It would be good if it was possible to bypass that.
It responds to the commands, quicker than expected, at least with albums/tracks in local. I have not tried with albums from NAS. Perhaps you are not familiar with HQPlayer and it needs some time for calculations especially conversions. PCM>PCM is pretty fast though.
It would be good that Playing Now feature was available for HQPlayer (at the moment it is not), otherwise it is not possible to know what track is playing from within Muso.
I could not experiment with Remote. I hope Antonello is going to do that.
All in all, at first sight, a very good first implementation - thanks.
BTW, HQPlayer v3.80b3 is available: http://www3.signalyst.com/bins/beta/
Re: support for HQplayer
I tested with my NAS - hqp-control implementation is pretty responsive. I don't see any problem in terms of speed/interactivity.
I can play whole albums, single tracks or add tracks to Queued Music which are automatically added to playlist in HQPlayer.
To recap there are three things missing:
1) to be able to open HQPlayer directly from Muso by sending playlist (that is without opening HQPlayer before);
2) to have Now Playing available for HQPlayer otherwise user remains in the dark;
3) "clear" command in Queued Music clears playlist in HQPlayer as well.
If the implementation works similarly with Remote, well...eureka!
I can play whole albums, single tracks or add tracks to Queued Music which are automatically added to playlist in HQPlayer.
To recap there are three things missing:
1) to be able to open HQPlayer directly from Muso by sending playlist (that is without opening HQPlayer before);
2) to have Now Playing available for HQPlayer otherwise user remains in the dark;
3) "clear" command in Queued Music clears playlist in HQPlayer as well.
If the implementation works similarly with Remote, well...eureka!
Re: support for HQplayer
Remote is currently not working with HQPlayer, but I know why - will be fixed. On the other points:bibo01 wrote:I tested with my NAS - hqp-control implementation is pretty responsive. I don't see any problem in terms of speed/interactivity.
I can play whole albums, single tracks or add tracks to Queued Music which are automatically added to playlist in HQPlayer.
To recap there are three things missing:
1) to be able to open HQPlayer directly from Muso by sending playlist (that is without opening HQPlayer before);
2) to have Now Playing available for HQPlayer otherwise user remains in the dark;
3) "clear" command in Queued Music clears playlist in HQPlayer as well.
If the implementation works similarly with Remote, well...eureka!
1) Yes this should be possible - will look into it for next release.
2) I'll' experiment with the --state and --playlist-get arguments to see if this can be achieved (am worried about performance though since I may have to query every second or so to keep the timeline updated).
3) Will look into this.
-
- Posts: 18
- Joined: Mon Jun 15, 2015 11:45 am
Re: support for HQplayer
in remote not work...tell no playermusoware wrote: I haven't tried remote yet, but it should just work since it's the muso engine doing the queueing.
[/URL]
Re: support for HQplayer
yeah I've just updated my post - I know why and have fixed, will be in next version, probably tonight.
-
- Posts: 18
- Joined: Mon Jun 15, 2015 11:45 am
Re: support for HQplayer
Great!!! Very THX!!!musoware wrote:yeah I've just updated my post - I know why and have fixed, will be in next version, probably tonight.
Re: support for HQplayer
Hmm, not sure I can reliably get now playing info since --playlist-get command is regularly returning a truncated playlist followed by "error: Premature end of document" - but not always. Perhaps this will be ironed out in the production version.
Re: support for HQplayer
Perhaps you guys can help me with something. The "hqp-control localhost --status" command is returning this info:
status: 2 3 0:22 0
The 3 is the playing track number and the 0:22 is the current play position. Any idea what the 2 and the 0 is? Neither seems to indicate whether playing or paused, the command may be missing that info.
status: 2 3 0:22 0
The 3 is the playing track number and the 0:22 is the current play position. Any idea what the 2 and the 0 is? Neither seems to indicate whether playing or paused, the command may be missing that info.
Re: support for HQplayer
New version for you to try, which should address most (if not all) of the issues identified so far (but there might still be others). The release number hasn't changed but the build number has been incremented, which means you will have to manually download the new install from the muso homepage (you won't be alerted there is an upgrade - but you can still upgrade without having to uninstall first).
This does include feedback of status (playing track & timeline, if configured). However, as all calls to hqp-control are synchronous (ie. have to wait for a reply) they have to be chained, Muso only queries it every 5 seconds by default. There is a new option to change this under the player config, but I'm finding that if I try it every second then hqp-control is not fast enough to respond. See how it works for you.
NB. I can't query the status every 5-10 seconds and just assume the timeline should tick along smoothly every second, because of the aforementioned issue that the --status command result does not indicate whether HQplayer is playing or is paused.
This does include feedback of status (playing track & timeline, if configured). However, as all calls to hqp-control are synchronous (ie. have to wait for a reply) they have to be chained, Muso only queries it every 5 seconds by default. There is a new option to change this under the player config, but I'm finding that if I try it every second then hqp-control is not fast enough to respond. See how it works for you.
NB. I can't query the status every 5-10 seconds and just assume the timeline should tick along smoothly every second, because of the aforementioned issue that the --status command result does not indicate whether HQplayer is playing or is paused.